Mailing-List: contact cygwin-announce-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-announce-owner AT sourceware DOT cygnus DOT com
Message-ID: <392B3814.55B182C8@cygnus.com>
Date: Tue, 23 May 2000 21:01:56 -0500
From: AJ Reins <tbisp AT cygnus DOT com>
MIME-Version: 1.0
To: cygwin-announce AT sourceware DOT cygnus DOT com
Subject: Bash 2.04 now available.
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I've just put a new bash update in the cygwin/latest/bash directory.
This is bash 2.04 with some additional fixes.

To update to the newest version, just download the newest version of
setup.exe and type:

                setup bash

Then, answer all of the questions using the same answers as the last
time you ran setup.

Please note that this procedure will only work on systems that have been
set up using the "setup.exe" program that is used since the release of
Cygwin 1.1.0.  If you still have B20.1 of Cygwin you'll need to upgrade
everything on your system.  Just type "setup" for that.

Below is a detailed description of what has changed in this release.

  Installed all patches from Chet (see below), tested and all seems to
be working fine.

  The following files are now able to ignore carriage returns:

   /etc/profile       ~/.bashrc        ~/.profile
   ~/.bash_profile    ~/.bash_login    ~/.bash_logout

   Also the files pointed to by the environment variables ENV and
   BASH_ENV.

  The file ~/.inputrc should still be ok since about Bash 2.03, as
there is code in there to ignore carriage returns that preceed line
feeds. I just hope that carriage returns can not follow a line feed as
that would probably slip through.

  The only file that I can see being a problem would be ~/.history
which is opened in binary mode for both reads and writes, so there
should be NO carriage returns in that file at all. As I believe this
is an INTERNAL file for use by Bash ONLY, I do not see any problems
with this file.

The patches from Chet as posted to gnu.bash.bug are:

1)   Patch-ID: bash204-001

        The +(pattern) operator does not work in all string modifying
        parameter expansions.  It works in ${parameter##word} but not
        ${parameter/pattern/string}.

2)   Patch-ID: bash204-002

   I might have misunderstood the functionality, but the man page reads:

       ${parameter:?word}
              Display  Error  if  Null or Unset.  If parameter is
              null or unset, the expansion of word (or a  message
              to  that  effect if word is not present) is written
              to the standard error and the shell, if it  is  not
              interactive, exits.  Otherwise, the value of param<AD>
              eter is substituted.

   If I source this one-liner, called "test.sh" and containing

    test ${9:?'generating a fatal error.'}

   by saying

    $ . ./test.sh

   what I get is that my _shell_ exits if $9 is unset. I tried even
   saying "set -i" in the one-liner itself or even explicitly saying
   bash -i then sourcing the one-liner, but my shell still exits.

3)   Patch-ID: bash204-003

        The { character isn't quoted when using filename completion.

4)   Superseded by 4a.

4a)  Patch-ID: bash204-004A
     Supersedes: bash204-004


   Bash behaves incorrectly on

    case "/tmp" in
      [/\\]*) exit 0;;
    esac
    exit 1

   The problem is with the bash `fnmatch':

        fnmatch ("/tmp", "[/\\\\]*]") fails to match, because after the `/'
        is matched, when brackmatch tries to skip the end of the
        characters list, it misses one of the `\', hence skips `\]' and
        then `*', and stops at `\0'.  Then it tries to fnmatch ("tmp", ""),
        which fails.

5)  Patch-ID: bash204-005
    Bug-Description:

     The behavior of the read command does not match the description
     of Word Splitting and IFS in the bash man page, and does not
     match the behavior of other shells (/bin/sh on Solaris, HP-UX,
     and Digital Unix).  Consider the following commands:

      sh-2.04$ IFS='() '
      sh-2.04$ read a b c d
      one (two) three four
      sh-2.04$ echo "$a"
      one
      sh-2.04$ echo "$b"
    
      sh-2.04$ echo "$c"
      two
      sh-2.04$ echo "$d"
      three four

     Apparently, the first space and the left parenthesis in the input
     string "one (two) three four" are being considered two separate
     delimiters (which is wrong), while the second space and right
     parenthesis are being considered a single delimiter (which is
     correct).  In other shells the variables a/b/c/d get the values
     one/two/three/four respectively.


6)  Patch-ID: bash204-005(should be 6)
    Bug-Description:

        The new prefix expansion operator ${!prefix*} is nice, but its
        sibling ${!prefix@} is not documented in the man page, and the
        behavior of "${prefix@}" seems wrong.  The expansions of
        ${!prefix*} and ${!prefix@} appear to be correctly the same,
        but the expansions of "${!prefix*}" and "${!prefix@}" appear to
        be incorrectly the same.  I would expect the behavior of
        "${!prefix@}" to be analogous to the expansion of "$@", where
        the individual expansions maintain identities as seperate
        arguments.

    Patch:

        The ${!prefix@} expansion is still undocumented, as it is in ksh93,
        from whence I cribbed it, but it now behaves analogously to "$@"
        when double-quoted.

7)  Patch-ID: bash204-007
    Bug-Description:

        Consider the following script

                #!/bin/sh -
                echo "a^@b"
                echo "`cat test.in`"

        With the input file test.in containing
                
                c^@d
        
        The string "^@" should be replaced with the null character. 
        
        "sh test.sh | od -a" gives
                
                0000000   a  nl   b  nl   c  nl
                0000006
                
        First of all, I wouldn't think that the replacement of the
        null character by a newline in the first command's output is
        correct.  Secondly, and more importantly, the loss of
        everything after the first null in the command substitution is
        a problem.

Also included is the patch that Earnie Boyd posted to the mailing list
(THANKS Earnie!):

      Add logic to change '\r' to '\n' in shell files.  This allows DOS style
      files to execute with binary mode mounts.


-- 
AJ Reins
Bash fanatic