New 1.3.4-blocking problem: execvp causes $0 to contain windows path instead of Unix path

Christopher Faylor
Tue Oct 30 18:10:00 GMT 2001

On Tue, Oct 30, 2001 at 06:16:25PM -0500, Christopher Faylor wrote:
>On Tue, Oct 30, 2001 at 05:18:57PM -0500, Jonathan Kamens wrote:
>>OK, this broke between 10/22 and 10/23.  It's almost certainly a
>>result of this change:
>>  date: 2001/10/22 16:40:26;  author: cgf;  state: Exp;  lines: +8 -0
>>  * libc/posix/execvp.c: Remove obsolete CYGWIN32 considerations throughout.
>>  * signal.h: Change comment to reflect __CYGWIN__ rather than __CYGWIN32__.
>>  * popen.c (popen): Use __CYGWIN_ rather than __CYGWIN32__.
>>  * system.c (_system_r): Ditto.
>>However, I can't see anything in this change that actually explains
>>why the bug would suddenly start happening.  I suspect that in fact
>>this change is correct but unmasked a previously existing bug.
>>I've got to leave in a few minutes.  I may or may not have time to
>>look at it more tonight; if not, I'll keep looking in the morning.
>It's caused by this change:
>2001-10-22  Christopher Faylor  <>
>        * (execvp): New function.
>        (execvpe): Ditto.
>I know what's causing the problem and expect to have a fix shortly.

Well, that was a lot trickier than I thought.  Looks like this was
actually a long-lived cygwin bug rather than something that I
recently introduced.

The reason that it never cropped up before is that, in rewriting execvp,
the find_exec function got more of a workout.  That function returns a
windows path when, 99% of the time, it should be returning a cygwin

I've checked in a fix but I notice that there is a testsuite signal
regression that I'm not tracking down, too.


More information about the Cygwin-developers mailing list