This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: cygwin Digest 25 May 2008 15:30:48 -0000 Issue 5990

Hi Christopher,

On Sun, May 25, 2008 at 6:30 PM,  <> wrote:

> Found: c:\Program Files\GnuWin32\bin\rm.exe
> Warning: C:\cygwin\bin\rm.exe hides c:\Program Files\GnuWin32\bin\rm.exe
> in your cygcheck output.  I wonder if you're running a non-cygwin version
> of sh (or make) somehow.
> ls -l `which make`
> ls -l `which sh`

I don't think this is the case. Both commands returned the executables
at /usr/bin.

Anyway, I believe that I've pin-pointed the behaviour of bash -c (when
executed as sh).

The fault is that executing

/bin/sh -c "cd <dir>"

will fail for <din> in the working folder unless it has a preceding "./"

For example

$ ls -d Code

$ /bin/sh -c "cd Code; pwd"
/bin/sh: line 0: cd: Code: No such file or directory

$ /bin/bash -c "cd Code; pwd"

$ /bin/ash -c "cd Code; pwd"

$ /bin/sh -c "cd ./Code; pwd"

Since /bin/sh is a copy of bash, it seems that somehow my bash
misbehaves when runnning in sh compatibility mode.

What is strange that this only happens on one computer. On a second
box I use with the same version this is not happening.

Thank you for the help.

- Gadi

Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]