This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: execlp/execvp needs case-correct PATH

On 11.02.2015 14:28, ext Corinna Vinschen wrote:
On Feb 10 20:14, Thomas Wolff wrote:
Am 10.02.2015 um 10:27 schrieb Corinna Vinschen:
On Feb  9 21:49, Thomas Wolff wrote:
Am 09.02.2015 um 11:17 schrieb Corinna Vinschen:
On Feb  9 00:04, Thomas Wolff wrote:
With a Windows case sensitive file system (and according mount flags
for /cygdrive), the PATH does not properly reflect casing of the actual
directories (e.g. C:\WINDOWS vs. C:\Windows, thanks MS...).
However, the shell finds programs anyway, like e.g. notepad.
The exec*p system calls, on the other hand, do not find a program in this
case as demonstrated by the attached test program.
This is in contrast to the Linux (and POSIX?) manual page which claims
âThe execlp(), execvp(), and execvpe() functions duplicate the actions
of the shell in searching for an executable file ââ
Sorry, I forgot one detail: I added /cygdrive/c/Windows/System32 to my path
so the shell will find it, but yet execlp does not find it.
Which makes sense, given that notepad is not in C:\Windows\System32, but in C:\Windows.
On my systems (Windows 7 Professional/Ultimate) itâs in both C:\Windows and
(otherwise the shell wouldnât have found it after adding to the path).

However, I could resolve the issue partly by putting
/cygdrive/c/Windows (or ../System32) in the path *before* the bogus
/cygdrive/c/WINDOWS - weird, but this way exec*p works.

With the old setting (bogus first in path), apparently/assumedly exec*p
somehow finds the file in /cygdrive/c/WINDOWS but then cannot start it from
there because of the case mis-match.
Thereâs still the inconsistency with shell behaviour.
I found the cause.  The function searching for executables in $PATH was
searching on the Win32 PATH variable.  The underlying conversion
functionality treats Win32 paths with default flags.  I revamped the
search function to iterate over the POSIX PATH variable so the
posix=[0|1] mount flag is taken into account.  As a nice side effect,
the search function is mow much simpler and easier to understand.

I tested this new stuff in a variety of situations, but there's still
the chance that I missed something.  So this needs a good, sturdy testing.

I just uploaded new snapshots to the usual place:

Please give it a try.
Excellent, thank you. I also tested with ping vs. PING vs. PING.EXE and behaviour is consistent.

Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]