Castor Fu wrote:
 On Wed, 16 Nov 2005, Dave Anderson wrote:
 > Castor Fu wrote:
 >
 >> The minimal expectation would be something which would export
 >>
 >>      pc->program_version
 >>
 >> If pc->curcmd were exported, that would also remove dependencies
 >> on calling cmd_usage.
 >>
 >
 > I do try my best to not muck with the basic data structures, and if changed,
 > to add the new struff onto the end of the data structure, so even if a module
 > were built with an older version, its dependencies would still be in place.
 > And with respect to the program_context structure specifically, I cannot
 > even remember the last time that it changed.  We can always put a
 > moratorium on the data structure to enforce the "only-add-to-the-end"
 > rule.  Or if you feel it's necessary, come up with a mechanism for
 > exporting stuff generically for extensions, come up with something
 > that we can put in extensions.c.
 If it doesn't change much, that's fine.
 Regarding the 'bt -O' change...  If I run 'crash' in root's $HOME
 a '.crashrc' will get executed twice.   I cannot put 'bt -O' in
 a .crashrc file and get predictable behavior.  It'd be good to
 have a mechanism which is idempotent.
 I've attached patches which change 'bt -O' to accept an optional 0/1
argument
 to fix the value. 
Well, first off, it's kind of stupid to run the same .crashrc file twice,
isn't it?  I shall fix that oversight henceforth...
That leaves the case where "bt -O" is set in both the $HOME and
local .crashrc files.  Whereas the local .crashrc is meant to override
whatever might be in the $HOME .crashrc, the "bt -O" case still wants
to be idempotent.  That can be addressed by a little tinkering with cmd_bt(),
because the pc->flags will have RCHOME_IFILE or RCLOCAL_IFILE
set when it's executing those .crashrc commands.
With those two fixes in hand, we can keep "bt -O" simple-minded.
Dave