Date: Sun, 14 Feb 1999 15:13:36 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: "Mark E." <snowball3 AT usa DOT net>
cc: djgpp-workers AT delorie DOT com
Subject: Re: new Bash 2.02.1 test version available
In-Reply-To: <199902101956.TAA74802@out1.ibm.net>
Message-ID: <Pine.SUN.3.91.990214150335.23494B-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: djgpp-workers AT delorie DOT com

I found several more problems with this test version:

  - "test -x foo" works backwards: it returns a status of 1 when `foo' 
    (or `foo.exe' etc.) *does* exist, and zero otherwise.  This, of 
    course, defeats many places in a typical configure script where it 
    looks for executables along PATH.

  - File-name completion behaves strangely on Windows 95, as far as 
    file-name letter-case is concerned.  For example, if I have three 
    files: GASP.EXE, gawk.exe, and gawk303.exe (in the letter-case as 
    shown), then typing "test -f ga<TAB>" causes Bash to up-case "ga" 
    into "GA".  Similarly, if I type "test -f gasp<TAB>", it completes to 
    "GASP.EXE".  Bash 1.14.7 didn't up-case such names, unless $FNCASE 
    was set to `y'.

    I think that up-casing 8+3 names is counter-intuitive to many users, 
    since the DJGPP library doesn't work that way by default.

  - .bash_history tends to get spurious ^M characters appended to some of 
    the saved commands.  I didn't play with that long enough to 
    understand under which conditions does that happen.  It might be 
    connected to the change that fixed the bug with mixed DOS/Unix text 
    format.