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