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