Mail Archives: djgpp-workers/2001/06/29/05:55:44
On Fri, 29 Jun 2001, Laurynas Biveinis wrote:
> > > 4) In this case IMO a new startup flag is the best solution.
> >
> > A startup flag is good for setting the default, but this should
> > really be configurable at run-time (say, a __dosexec_search_mode
> > variable). That way bash can have, say, 'set +commandcomstyleexec'
> > or an option in _inputrc to switch between modes. I'd want a
> > change to the behaviour an app requests to be a conscious user
> > choice; having an envvar that is checked by libc doesn't feel
> > right.
>
> IMHO we should have an env variable too - so a conscious user doesn't
> have to change the code, just relink apps, in order to change the
> behaviour. And a startup flag / runtime variable is required too, so
> apps, like bash, may have a reasonable default.
How about this, then:
* make libc's behaviour steerable by a control variable and document that.
* Bash would then check some environment variable to decide what it
wants to set that control variable to.
I'd prefer an environment variable because we have prior art in that area,
regarding DJGPP bash --- TEST_FINDS_EXE and all those. It'd fit into the
global picture more easily, that way. *And* it could be controllable at
runtime, by changing that environment variable, without too much effort.
I don't think it'd be wise to make libc behaviour directly depend on that
environment variable --- it'd affect just *too* many programs, blindly
assuming they all are to be treated equally.
Bash sources would bring this special version of dosexec.c with them, but
check for precense of that control variable in libc, too. If it's found,
it would use the libc version, assuming that it's newer than bash's own
copy.
--
Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.
- Raw text -