Mail Archives: cygwin/2000/05/23/22:14:46
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 AT sourceware DOT cygnus DOT com
- Raw text -