[Crash-utility] Miscellaneous fixes/enhancements to crash 4.0-2.10(fwd)

[Dave Anderson]

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