Mail Archives: cygwin-developers/2001/10/30/21:10:18
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 <cgf AT redhat DOT com>
>
>[snip]
> * exec.cc (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
path.
I've checked in a fix but I notice that there is a testsuite signal
regression that I'm not tracking down, too.
cgf
- Raw text -