Re: Bash-3.1 Official patch 10
Chet Ramey wrote:
> There is a difference in behavior between bash-3.0 and bash-3.1 involving
> parsing of single- and double-quoted strings occurring in old-style
> command substitution. The difference has to do with how backslashes are
> processed. This patch restores a measure of backwards compatibility while
> the question of POSIX conformance and ultimately correct behavior is
> discussed.
Hi,
It appears there might be problem with this patch. Here is a test case I
distilled from the grep-2.5.1a testsuite:
status=`echo '-'| { ${GREP} -E -e 'a\' >/dev/null 2>&1 ; echo $?; }`
Put that line into a file called "myfile" then run like this:
# bash -n myfile
myfile: line 1: unexpected EOF while looking for matching `''
myfile: line 2: syntax error: unexpected end of file
AFAICT, this used to be accepted by older Bash versions.
Do think problem lies with this Bash patch or with test case?
Thanks
Greg
--
http://www.diy-linux.org/
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Bash-3.1 Official patch 10
Chet Ramey wrote:
> There is a difference in behavior between bash-3.0 and bash-3.1 involving
> parsing of single- and double-quoted strings occurring in old-style
> command substitution. The difference has to do with how backslashes are
> processed. This patch restores a measure of backwards compatibility while
> the question of POSIX conformance and ultimately correct behavior is
> discussed.
Hi,
It appears there might be problem with this patch. Here is a test case I
distilled from the grep-2.5.1a testsuite:
status=`echo '-'| { ${GREP} -E -e 'a\' >/dev/null 2>&1 ; echo $?; }`
Put that line into a file called "myfile" then run like this:
# bash -n myfile
myfile: line 1: unexpected EOF while looking for matching `''
myfile: line 2: syntax error: unexpected end of file
AFAICT, this used to be accepted by older Bash versions.
Do you think problem lies with this Bash patch or with test case?
Thanks
Greg
--
http://www.diy-linux.org/
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
[PATCH] Robustify configure check for /dev/fd
Hi This issue was reported earlier but with apparently no response: http://lists.gnu.org/archive/html/bug-bash/2006-05/msg00018.html When su'd to a non-root user under Linux the configure check fails: checking whether /dev/fd is available... absent Here is a suggested patch as per the following analysis: http://linuxfromscratch.org/pipermail/lfs-dev/2006-August/057860.html diff -Naur bash-3.1.orig/aclocal.m4 bash-3.1/aclocal.m4 --- bash-3.1.orig/aclocal.m42005-05-09 19:23:14.0 + +++ bash-3.1/aclocal.m4 2006-08-14 02:45:30.0 + @@ -1542,7 +1542,7 @@ AC_CACHE_VAL(bash_cv_dev_fd, [if test -d /dev/fd && test -r /dev/fd/0 < /dev/null; then # check for systems like FreeBSD 5 that only provide /dev/fd/[012] - exec 3<&0 + exec 3http://lists.gnu.org/mailman/listinfo/bug-bash
functions and set -e
Hi
Here's a test case which demonstrates the problem:
#!/bin/sh
set -e
func () {
false && echo false
true && echo true
false && echo false
}
func
echo done
It never echoes "done" because func() returns 1. This seems to go against
what the bash manual says about "set -e"
"Exit immediately if a simple command (*note Simple Commands::) exits with a
non-zero status, unless the command that fails is part of the command list
immediately following a `while' or `until' keyword, part of the test in an `if'
statement, part of a `&&' or `||' list,"
The problem appears to be specific to functions. Is this a bug?
Thanks
Greg
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Re: functions and set -e
On Wed, Aug 30, 2006 at 12:03:51AM -0400, Paul Jarc wrote:
> Greg Schafer <[EMAIL PROTECTED]> wrote:
> > #!/bin/sh
> > set -e
> >
> > func () {
> > false && echo false
> > true && echo true
> > false && echo false
> > }
> >
> > func
> >
> > echo done
> >
> >
> > It never echoes "done" because func() returns 1.
>
> That's the correct behavior. The last "false" within the function
> does not immediately cause bash to exit, since it is part of the "&&"
> comound statement. But then the function call itself, which is a
> simple command in its own right, has a nonzero exit status, so bash
> exits at that point.
I'll take your word for it.. but I'm not totally convinced. At the very
least, this behavior is very confusing and apparently not documented. It's
just plain weird that the compound statement containing "false" causes the
function call to end up with a nonzero exit status only bacause the
statement appears *on the last line* of the function. The exact same
statement on the first line of the function behaves as expected.
Regards
Greg
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Re: functions and set -e
On Wed, Aug 30, 2006 at 04:28:35AM +, Eric Blake wrote:
> > > > #!/bin/sh
> > > > set -e
> > > >
> > > > func () {
> > > > false && echo false
> > > > true && echo true
> > > > false && echo false
> ^^^ Line 1
>
> > > > }
> > > >
> > > > func
> ^^^ Line 2
>
> > > >
> > > > echo done
> > > >
> > I'll take your word for it.. but I'm not totally convinced. At the very
> > least, this behavior is very confusing and apparently not documented. It's
> > just plain weird that the compound statement containing "false" causes the
> > function call to end up with a nonzero exit status only bacause the
> > statement appears *on the last line* of the function. The exact same
> > statement on the first line of the function behaves as expected.
>
> As marked above, the line causing bash to exit is not line 1 (which
> was a compound statement), but line 2 (invoking a function by a
> simple statement). Try rewriting line 2 as "func && echo false" to
> see the difference.
Thanks for trying to clarify it for me. Let me put it another way: If I
change Line 1 above to an if/then style statement instead of "&&" ie:
if false; then echo false; fi
it works exactly like I'd expect instead of the counter-intuitive behavior
when using &&.
I still suspect something is amiss here. Maybe the bash docs just need to be
clarified.. Anyhoo, I suppose I should have tested with other shells before
reporting but I don't have any available at the moment..
Regards
Greg
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Re: functions and set -e
On Wed, Aug 30, 2006 at 01:01:06AM -0400, Paul Jarc wrote: > Greg Schafer <[EMAIL PROTECTED]> wrote: > > Thanks for trying to clarify it for me. Let me put it another way: If I > > change Line 1 above to an if/then style statement instead of "&&" ie: > > > > if false; then echo false; fi > > > > it works exactly like I'd expect instead of the counter-intuitive behavior > > when using &&. > > That's because the exit status if an "if" command with a false > condition and no "else" clause is 0, while the status of the "&&" > command is not. > > bash is behaving exactly as the documentation says: the function call > itself is a simple command, so if it returns nonzero, bash exits. That is the crux of the problem. I was expecting the function to return zero. But as you quite rightly say, the exit status of the "&&" command in this instance is nonzero and this is the key point I was missing. It's covered in the "Lists of Commands" section of the manual: "The return status of AND and OR lists is the exit status of the last command executed in the list." Ok, sorted. Thanks for your patience. I'm gonna put this down as a trap for young players :-) Regards Greg ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
bash-3.2 parse error
Hi ncurses-5.5 fails to build with bash-3.2 installed as sh. Here's the distilled testcase: cat > testcase << "EOF" TABSIZE=`grep -v '^[ #]' $CAPS | grep -v "^$" | grep -v "^capalias"| grep -v "^infoalias" | wc -l` EOF $ bash -n testcase testcase: line 1: unexpected EOF while looking for matching ``' testcase: line 2: syntax error: unexpected end of file It appears to be the `#' character in between the single quotes giving the grief. That line works with every bash version prior to 3.2. Thoughts? Thanks Greg ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
intl.tests failure
Hi, Sorry for not noticing this earlier but bash-3.2 bash has introduced a minor regression in my build environment (i686-pc-linux-gnu): warning: some of these tests will fail if you do not have UTF-8 warning: locales installed on your system. warning: please ignore any differences consisting only of white space 2c2 < 2 --- > 1 8,10c8,10 < aÃb < 000 141 303 142 < 003 --- > aéb > 000 141 303 251 142 > 004 I have LC_ALL=C set in my build environment. Remming out the call to set_default_lang() in shell.c makes the testsuite pass as does running the testsuite like this: make tests LC_ALL= Maybe this test needs some robustification, thoughts? Regards Greg ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
