[Mingw-msys] A gift for Max - bash-2.05b
On Sat, 2007-09-22 at 17:29 +0000, John Brown wrote:
> If you have a directory foo in the same directory as foo.exe, then you
> must type 'foo.exe' to run foo. If you type 'foo', it returns:
> $ foo
> sh: foo: command not found
I believe it will also do this if you have a file called `foo' in the
same directory as `foo.exe', and that file cannot be executed; I am
certain that a script called `foo' will be executed in preference to
`foo.exe', when both exist and the script is executable.
> foo.exe is definitely in the $PATH. Not that it matters, because
> I get the same result when I am in the directory that contains
> foo/ and foo.exe.
> I am running bash 3.1.0(3)-release (i686-pc-msys) on Windows XP,
> but I am fairly sure that it has always been that way.
It certainly did work this way in MSYS-1.0.9 and MSYS-1.0.10.
> Is this by design?
Possibly not by design, but it is a natural consequence of how the PATH
is searched for the executable. I'm not certain, but it may even be
this way in native cmd.exe, but when you specify the command name with
no explicit suffix, (and I believe cmd.exe even discards the suffix if
you *do* specify it):--
1) In cmd.exe, the current directory is always searched first; in MSYS
bash this is true, only when `.' is the first entry in PATH, (which is
the default configuration).
2) The search initially looks for an entity with the bare name, without
any suffix; if that is found, the shell immediately tries to execute it.
3) If no bare name is matched, then the search is retried in the same
directory, with recognised executable extensions added in turn, until a
match is found, or until all suitable extensions have been tried; MSYS
may try only `.exe', (I'm not completely certain); cmd.exe tries several
others, such as `.com' and `.bat'; as soon as a matching file is found,
the shell stops searching in that directory, and tries to execute it.
4) If no suitable match is identified, either in step (2) or step (3),
or, I believe, if the first matched file in that directory cannot be
executed, the search immediately progresses to the next directory, if
any in the PATH, and the search process is repeated from step (2).
Not that any of this solves your problem, but perhaps it explains it;
the solution is to avoid having other directories or files with the same
`foo' base name, in the `bin' directory where you install `foo.exe'.
The hierarchy, which would be adopted on a *nix system, would be
Perhaps you could consider something similar.
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
Mingw-msys mailing list