Mail Archives: djgpp-workers/2001/07/02/06:37:38
On Mon, 2 Jul 2001, Mark E. wrote:
> So in the case of Bash, having __spawnve in dosexec.c perform an extension
> search is redundant since one has already been done. And performing this
> additional search can and does cause a different file than the one passed to
> spawn* to be executed.
>
> Therefore, I (and others?) want to help out Bash by providing a way to direct
> __spawnve to not perform this search.
How about splitting __spawnve into two parts: one which performs the
extension search, the other which does the rest? Then Bash could call
the function which does the latter, instead of `spawnve', and `spawnve'
will call this new function internally, after it performs its own search.
Since currently, the extension search also finds the ``interpreter''
needed to run the program, you might need a separate argument to pass to
this new function, telling it what is the interpreter. If that argument is
NULL (which it will be in the case of Bash), it will scan the interpreters'
data base to find one, given the extension.
With such a design, __spawnve doesn't need to change its API, and its
inner workings will change only a little, due to code rearrangement.
This has an advantage of avoiding the risk of breaking existing
functionality.
> Does __dos_exec_find_on_path do its own extension search?
Yes, it does.
> So at the moment I'm more interested in solving the second problem (with
> __spawnve) rather than the first (getting the search order in shape if it
> isn't already).
A separate question is whether we are sure what Bash does today is
correct. I was under an impression that some people in this thread
didn't think so. I think Tim wanted an extensionless shell script be
invoked in preference to a .exe program, and I'm not sure whether Bash
does that.
- Raw text -