Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-developers-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin-developers AT sources DOT redhat DOT com Date: Tue, 30 Oct 2001 21:11:07 -0500 From: Christopher Faylor To: cygwin-developers AT cygwin DOT com Subject: Re: New 1.3.4-blocking problem: execvp causes $0 to contain windows path instead of Unix path Message-ID: <20011030211107.A19801@redhat.com> Reply-To: cygwin-developers AT cygwin DOT com Mail-Followup-To: cygwin-developers AT cygwin DOT com References: <20011030185024 DOT 32684 DOT qmail AT lizard DOT curl DOT com> <20011030221857 DOT 2548 DOT qmail AT lizard DOT curl DOT com> <20011030181625 DOT B17034 AT redhat DOT com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011030181625.B17034@redhat.com> User-Agent: Mutt/1.3.21i 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 > >[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