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