This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: cygwin Digest 25 May 2008 15:30:48 -0000 Issue 5990
- From: "Gadi Oron" <gadior at gmail dot com>
- To: cygwin at cygwin dot com
- Date: Mon, 26 May 2008 08:50:23 +0300
- Subject: Re: cygwin Digest 25 May 2008 15:30:48 -0000 Issue 5990
- References: <1211729448.28588.ezmlm@cygwin.com>
Hi Christopher,
On Sun, May 25, 2008 at 6:30 PM, <cygwin-digest-help@cygwin.com> 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
Code/
$ /bin/sh -c "cd Code; pwd"
/bin/sh: line 0: cd: Code: No such file or directory
/home
$ /bin/bash -c "cd Code; pwd"
/home/Code
$ /bin/ash -c "cd Code; pwd"
/home/Code
$ /bin/sh -c "cd ./Code; pwd"
/home/Code
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: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/