Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Delivered-To: mailing list cygwin@cygwin.com Message-ID: <4153565F.F9777333@dessent.net> Date: Thu, 23 Sep 2004 16:03:59 -0700 From: Brian Dessent Organization: My own little world... MIME-Version: 1.0 To: cygwin@cygwin.com Subject: Re: Same code, same script, different results References: <007501c4a172$a96aa9e0$b200a8c0@mindcooler> <002201c4a189$1b126b80$b200a8c0@mindcooler> Content-Type: text/plain; charset=iso-8859-1 X-IsSubscribed: yes Reply-To: cygwin@cygwin.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id i8NN1CM2014035 Mikael Åsberg wrote: > Anyway, it's working as expected now. But to tell the truth I don't know > exactly what the problem was. I tinkered some with the script, did a make > clean ; make (again), and, voila, it works. I'm glad that it works, but it's > a bit annoying not understanding what the problem and the rememdy was. You had DOS line endings (\r\n) on your bash script. To bash the \r is just another character, not a line ending, and it was being included with the other arguments. Thus argv[2] was really "--non-recursive\r" which caused the nonzero strcmp() result. The difference between the two testcases results from the fact that argument parsing is done by the runtime of the compiler/library. In Windows there's really only one long command string for the process, it's the job of the CRT to parse it into words for argv[]. The MSVCRT treated the spurious \r as whitespace and did not include it in argv[2] whereas the Cygwin runtime made no such assumption. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/