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: 30 Oct 2001 13:50:24 -0500 Message-ID: <20011030185024.32684.qmail@lizard.curl.com> From: Jonathan Kamens To: cygwin-developers AT cygwin DOT com Subject: New 1.3.4-blocking problem: execvp causes $0 to contain windows path instead of Unix path Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart_Tue_Oct_30_13:50:24_2001" Content-Transfer-Encoding: 7bit --Multipart_Tue_Oct_30_13:50:24_2001 Content-Type: text/plain; charset=US-ASCII Save the enclosed files in a directory. Run "gcc -o execvp execvp.exe" in that directory. Then run "/test-rel.sh". It should print "../../src/configure", but instead it'll print a Windows path, starting with a drive letter and containing backslashes and everything. If you change execvp.c so that it uses "execv" instead of "execvp" and then recompile it, the output of the test script will be correct. This broke between the 20011020 snapshot and the 20011024 snapshot. I will investigate more this afternoon, but not for the next few hours (I have a meeting which I need to prepare for and attend), if somebody else doesn't beat me to it. jik --Multipart_Tue_Oct_30_13:50:24_2001 Content-Type: text/plain; name="test-rel.sh"; charset=US-ASCII Content-Transfer-Encoding: 7bit #!/bin/sh -e execvp=`dirname $0`/execvp cd /tmp mkdir -p src build/win32 cd src rm -f configure cat >configure <<\EOF #! /bin/sh echo $0 EOF chmod +x configure cd ../build/win32 $execvp ../../src/configure --Multipart_Tue_Oct_30_13:50:24_2001 Content-Type: text/plain; name="execvp.c"; charset=US-ASCII Content-Transfer-Encoding: 7bit #include main(int argc, char *argv[]) { --argc; ++argv; execvp(*argv, argv); } --Multipart_Tue_Oct_30_13:50:24_2001--