X-Spam-Check-By: sourceware.org
Message-ID: <451C7386.4050001@cygwin.com>
Date: Thu, 28 Sep 2006 21:14:46 -0400
From: "Larry Hall (Cygwin)" <reply-to-list-only-lh AT cygwin DOT com>
Reply-To: cygwin AT cygwin DOT com
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.5) Gecko/20060727 Fedora/1.5.0.5-1.fc4.remi Thunderbird/1.5.0.5 Mnenhy/0.7.4.0
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: Similar Bash 3.1.18 CR/LF Problem
References: <657A9BE009D3504AAE29BD8E8C2DD61E01A5ABDB AT SDGEXEVS02 DOT corp DOT intuit DOT net>
In-Reply-To: <657A9BE009D3504AAE29BD8E8C2DD61E01A5ABDB@SDGEXEVS02.corp.intuit.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

Wilks, Dan wrote:
>>> Apologies that this is being written the day after without real
> output.
>>> I'm now at my desk without easy access to the machine in question.
>>> But...
>>>
>>> We've been using Cygwin with text-mode mounts for a long time
> without
>>> any problems.  A new engineer started the other day, installed a
>>> brand-spanking-new cygwin and came to me with problems running a
> build.
>>> Without going into details of the build system, after a few hours I
>>> discovered that (all examples are from a cmd shell), foo.sh contains
> the
>>> single line "date; date<cr><lf>"
>>>
>>>    C:> cd temp
>>>    C:\temp> sh foo.sh      -- works
>>>    C:\temp> sh C:/temp/foo.sh  - fails
>>>    C:\temp> sh C:\temp\foo.sh  - fails
>>>
>>> The failures were of a form where the first command on a line works
> but
>>> the second generates an error.  Removing the trailing eol on the
> on-line
>>> shell script allows the scripts to work regardless of how they're
>>> specified on the sh command line.
>>>
>>> Sorry, I don't remember trying sh /cygdrive/c/temp/foo.sh but if I
> did
>>> it also failed because I know the only way I could get it to work
> was
>>> w/o any path component.
>>
>> What about "bash <all variations>".
> 
> Bash fails in exactly the same way that sh does.  I was able to get
> the real output that I should have gotten originally.  :)
> 
> -rwxr-x---+ 1 ahuddles mkgroup-l-d 461824 Sep 14 03:21 bash.exe
> -rwxr-x---+ 1 ahuddles mkgroup-l-d 461824 Sep 28 13:20 sh.exe
>  
> C:\Temp>mount
> C:\cygwin\bin on /usr/bin type system (textmode) C:\cygwin\lib on
> /usr/lib type system (textmode) C:\cygwin on / type system (textmode)
> c: on /cygdrive/c type system (textmode,noumount)
> h: on /cygdrive/h type system (textmode,noumount)
> i: on /cygdrive/i type system (textmode,noumount)
> r: on /cygdrive/r type system (textmode,noumount)
> s: on /cygdrive/s type system (textmode,noumount)
> u: on /cygdrive/u type system (textmode,noumount)
> 
> C:\Temp>od -c foo.sh
> 0000000   d   a   t   e   ;       d   a   t   e  \r  \n
> 0000014
> 
> C:\Temp>od -t x1 foo.sh
> 0000000 64 61 74 65 3b 20 64 61 74 65 0d 0a
> 0000014
> 
> C:\Temp>sh foo.sh
> Thu Sep 28 13:21:46 PDT 2006
> Thu Sep 28 13:21:46 PDT 2006
>  
> C:\Temp>sh c:/Temp/foo.sh
> Thu Sep 28 13:21:52 PDT 2006
> : command not founde 1: date
>  
> C:\Temp>sh c:\Temp\foo.sh
> Thu Sep 28 13:21:58 PDT 2006
> : command not founde 1: date
>  
> C:\Temp>sh /cygdrive/c/Temp/foo.sh
> Thu Sep 28 13:22:07 PDT 2006
> Thu Sep 28 13:22:08 PDT 2006
>  
> C:\Temp>bash foo.sh
> Thu Sep 28 13:22:12 PDT 2006
> Thu Sep 28 13:22:12 PDT 2006
>  
> C:\Temp>bash c:/Temp/foo.sh
> Thu Sep 28 13:22:17 PDT 2006
> : command not founde 1: date
>  
> C:\Temp>bash c:\Temp\foo.sh
> Thu Sep 28 13:22:23 PDT 2006
> : command not founde 1: date
>  
> C:\Temp>bash /cygdrive/c/Temp/foo.sh
> Thu Sep 28 13:22:36 PDT 2006
> Thu Sep 28 13:22:36 PDT 2006

Ah, so POSIX paths do work.  That makes sense, given your mounts.  The
moral to the story is that if you want text files to work transparently
with your text mounts, use POSIX paths so the mount points and attributes
are respected.  Using DOS path notation bypasses the mount table so all
bets are off.

-- 
Larry Hall                              http://www.rfk.com
RFK Partners, Inc.                      (508) 893-9779 - RFK Office
216 Dalton Rd.                          (508) 893-9889 - FAX
Holliston, MA 01746

--
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/