Bash Version: 3.1
Patch Level: 11
Release Status: release
Description:
In other shells (like bash 3.0, bash 2.x, zsh, dash),
for VARIABLE; do ...; done
is equivalent to
for VARIABLE in "$@"; do ...; done
GNU autoconf also relies on this fact at many points:
ac_prev=
for ac_option
do
# If the previous option needs an argument, assign it.
if test -n "$ac_prev"; then
eval "$ac_prev=\$ac_option"
ac_prev=
continue
fi
ac_optarg=`expr "x$ac_option" : 'x[^=]*=\(.*\)'`
The problem becomes quite visible in that configure scripts seem to ignore
parameters line --prefix. libtool does not work either...
mode=link
for arg
do
case $arg in
-c)
mode=compile
Too bad that this does not work in bash 3.1 any more (3.1 without the patches
is also affected).
It at least happens on FreeBSD/x86 and _did_ happen on Gentoo/PPC but
apparently got fixed. On some other platforms like FC4/x86 it does NOT happen.
Repeat-By:
rpolzer@katsuragi /tmp/bash/bin $ set -- a b c
rpolzer@katsuragi /tmp/bash/bin $ echo "$@"
a b c
rpolzer@katsuragi /tmp/bash/bin $ for V; do echo $V; done
rpolzer@katsuragi /tmp/bash/bin $ for V in "$@"; do echo $V; done
a
b
c
rpolzer@katsuragi /tmp/bash/bin $ help for
for: for NAME [in WORDS ... ;] do COMMANDS; done
The `for' loop executes a sequence of commands for each member in a
list of items. If `in WORDS ...;' is not present, then `in "$@"' is
assumed. For each element in WORDS, NAME is set to that element, and
the COMMANDS are executed.
for ((: for (( exp1; exp2; exp3 )); do COMMANDS; done
Equivalent to
(( EXP1 ))
while (( EXP2 )); do
COMMANDS
(( EXP3 ))
done
EXP1, EXP2, and EXP3 are arithmetic expressions. If any expression is
omitted, it behaves as if it evaluates to 1.
[Describe the sequence of events that causes the problem
to occur.]
rpolzer@katsuragi /tmp/bash/bin $ set -xv
rpolzer@katsuragi /tmp/bash/bin $ for X; do echo $X; done
for X; do echo $X; done
+ for X in '""'
+ echo
> Bash Version: 3.1
> Patch Level: 11
> Release Status: release
>
> Description:
>
> In other shells (like bash 3.0, bash 2.x, zsh, dash),
>
> for VARIABLE; do ...; done
>
> is equivalent to
>
> for VARIABLE in "$@"; do ...; done
And it is in bash, too. When this has been reported in the past, it
has been due to a bug in the version of bison used to generate the
parser from parse.y. I cannot remember the exact version of bison
that's at fault, and can't easily find it right now, but that is the
culprit.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
( ``Discere est Dolere'' -- chet )
Live Strong. No day but today.
Chet Ramey, ITS, CWRU ch...@case.edu http://cnswww.cns.cwru.edu/~chet/