X-Spam-Check-By: sourceware.org
X-SBRS: None
X-IronPort-AV: i="4.09,231,1157353200";     d="scan'208"; a="65376919:sNHT16933938"
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; 	charset="us-ascii"
Subject: RE: Similar Bash 3.1.18 CR/LF Problem
Date: Thu, 28 Sep 2006 14:59:46 -0700
Message-ID: <657A9BE009D3504AAE29BD8E8C2DD61E01A5ABDB@SDGEXEVS02.corp.intuit.net>
In-Reply-To: <451C14F7.2020707@cygwin.com>
From: "Wilks, Dan" <Dan_Wilks AT intuit DOT com>
To: <cygwin AT cygwin DOT com>
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
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
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id k8SLxunA030595

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

> >
> > Oh, and when we downloaded just bash 3.1.6(17?) it didn't overwrite
the
> > old sh.
> 
> 
> That suggests the postinstall script didn't run for some reason.
> 

That was my guess.  But since this was the cygwin installer run off 
of the cygwin site I thought I'd mention it, if for no other reason 
than tracking purposes.  Maybe there's a problem with the installer /
postinstall script when downgrading? Or perhaps that's intended 
behavior.  It was just surprising.

And... it didn't run again when re-upgrading just bash to the new
(broken) version so we had to manually copy bash.exe to sh.exe.

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