delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2000/07/06/14:09:19

Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sourceware DOT cygnus DOT com>
List-Archive: <http://sourceware.cygnus.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sourceware DOT cygnus DOT com>
List-Help: <mailto:cygwin-help AT sourceware DOT cygnus DOT com>, <http://sourceware.cygnus.com/ml/#faqs>
Sender: cygwin-owner AT sourceware DOT cygnus DOT com
Delivered-To: mailing list cygwin AT sourceware DOT cygnus DOT com
Message-ID: <3964CB41.E558080A@veritas.com>
Date: Thu, 06 Jul 2000 11:09:05 -0700
From: Bob McGowan <rmcgowan AT veritas DOT com>
Organization: VERITAS Software
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: cygwin AT sourceware DOT cygnus DOT com
Subject: Re: cd ....
References: <3964BB6B399 DOT E1F4SOHDA AT matsulab DOT is DOT titech DOT ac DOT jp> <20000706134323 DOT G20864 AT cygnus DOT com>

There is a difference between the Windows handling of this and what
bash/cygwin is doing.  Windows cmd (on NT 4.0) appears to ignore the
request.  The current directory does not change and cd with no args
gives the same current path as existed before trying the 'cd ...'
command.

bash/cygwin is "changing" to the specified location, so pwd reports the
'new' path, as was given in the cd request.  But an ls shows the
directory contents are the same as for the starting directory, so no
change has actually happened.

I also found that this only works one level deep for bash/cygwin:

    $ cd ..../....
    bash: cd: ..../....: No such file or directory

But cmd treats this the same as a single level.

Are these the expected behaviors?

Chris Faylor wrote:
> 
> On Fri, Jul 07, 2000 at 02:01:31AM +0900, Yukihiko Sohda wrote:
> >Hi,
> >
> >I reports a trivial(?) bug.
> >"cd" accepts illegal path like this.
> >
> >[/]cd ...
> >[/...]cd ..
> >[/]cd ...
> >[/...]cd ...
> >[/.../...]cd ..
> >[/.../.../..]cd /
> >[/]cd ...........
> >[/...........]pwd
> >/...........
> >[/...........]
> >
> >I examined this with the following cygwin1.dll,
> >and got the similar result.
> >
> >- CYGWIN_NT-5.0 WOODSTOCK 1.1.2(0.21/3/2) 2000-06-06 22:20 i686 unknown
> >- CYGWIN_NT-5.0 WOODSTOCK 1.1.3s(0.24/3/2) 2000-07-04 23:55 i686 unknown
> 
> Have you tried the same thing with Windows?  Windows accepts these paths.
> 
> I don't want to add a check in the already overburdened path handling code
> just to stop somebody from doing something that is valid on Windows.
> 
> cgf
> 
> --
> Want to unsubscribe from this list?
> Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com

-- 
Bob McGowan
Staff Software Quality Engineer
VERITAS Software
rmcgowan AT veritas DOT com

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019