Mail Archives: djgpp-workers/2001/07/02/01:31:49
OK gang, let's at least try to get it straight what Bash extension search
order should be and what changes to libc are needed to allow it.
When you type in a command to run and Bash finds that it is a program to be
run from disk, it searches PATH for the program to run. I hook into this to
perform an extension search if a file without an extension doesn't exist.
Once the file is found and isn't found to be a directory or something else
icky, Bash creates the argument array and calls execve. In our case, Bash
calls spawnve. So by the time spawnve is called, Bash has already taken the
trouble to find the file to run and (unless disabled) has put the program's
name into a hash table so it doesn't have to search PATH again.
The current extension search in Bash 2.05 prefers to execute the filename as-
is. If the file doesn't exist, then an extension search is done. If the file
is an unstubbed coff file, then it isn't executed if an .exe also exists.
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. Some possible ways of doing this:
* A run-time flag to tell __spawnve not to perform a search. But what about
the spawn "p" variations that search the path. Does __dos_exec_find_on_path
do its own extension search?
* A callback of some sort.
* A new spawn variant that would signal __spawnve to not perform the search.
I don't hashing out the "proper-and-correct (tm)" search method for Bash is
as important as being able to let Bash be able to use its own search method.
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).
Mark
- Raw text -