[ANNOUNCEMENT] Bash 2.04 now available.

Tue May 23 19:08:00 GMT 2000

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
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com