Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Date: Wed, 12 May 2004 12:17:12 -0400 From: "Pierre A. Humblet" To: cygwin AT cygwin DOT com Subject: Re: bash: tab completion failure from (but not at) / Message-ID: <20040512161712.GA349175@Worldnet> References: <20040512140835 DOT GJ12030 AT cygbert DOT vinschen DOT de> <20040512154332 DOT GO12030 AT cygbert DOT vinschen DOT de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040512154332.GO12030@cygbert.vinschen.de> User-Agent: Mutt/1.4.1i On Wed, May 12, 2004 at 05:43:32PM +0200, Corinna Vinschen wrote: > On May 12 16:17, Dave Korn wrote: > > I reckon you could quote > > http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap04.html#tag_0 > > 4_11 > > to support the claim that what bash is doing is actually an invalid > > transformation and should be considered a bug. That page says > > > > "A pathname consisting of a single slash shall resolve to the root directory > > of the process. A null pathname shall not be successfully resolved. A > > pathname that begins with two successive slashes may be interpreted in an > > implementation-defined manner, although more than two leading slashes shall > > be treated as a single slash." > > > > Therefore translating "/" to "//" has the effect of replacing an > > unambiguous specs-defined interpretation with an implementation-defined > > interpretation and is clearly invalid, even though it amounts to a null > > tranformation on many *nix systems. > > Looking into the bash code, you'll see that this is a well-known fact > to the bash developers. This bug just couldn't be easily uncovered, > since it doesn't result in wrong behaviour on any system so far. Sheer > luck that two bugs met each other :-) > I would argue that Corinna's change is a good temporary patch, until bash is fixed, but that in the long run we should just apply the Posix law. Allowing // to mean / gives strange results: ~> /bin/ls // alt bin ~> /bin/ls -l // /bin/ls: //alt: No such file or directory /bin/ls: //bin: No such file or directory ~> /bin/ls "/ . ." alt bin (1.5.9 also screws up on that one, but in a different way) Pierre -- 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/