Bug 79626

Summary: for is seriously broken
Product: [Retired] Red Hat Linux Reporter: Sami Farin <safari+rhbug>
Component: bashAssignee: Tim Waugh <twaugh>
Status: CLOSED WORKSFORME QA Contact: Ben Levenson <benl>
Severity: low Docs Contact:
Priority: low    
Version: 8.0   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard: bug in for_command and select_command caused by bug in bison-1.50 - 1.75
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2002-12-15 18:09:54 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Sami Farin 2002-12-14 05:02:30 UTC
Description of problem:

$ 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.

now, look how it really works.

$ cat fortest1.sh 
for x
  do echo foo "${x}"

$ cat fortesta.sh 
for x
  do echo foo "${x}"

$ cat fortestb.sh 
for x
  do echo foo "${x}"

$ ./fortest1.sh worked since the \'90s
foo worked
foo since
foo the
foo '90s

$ ./fortesta.sh works very well
foo works
foo very
foo well

$ ./fortestb.sh breaks insanely

examples of ways this bash version breaks in the real life:

$ libtoolize --help
libtoolize: too many arguments
Try `libtoolize --help' for more information.

and when using "libtool --debug *anything*", I get:
+ echo 'libtool: compile: cannot determine name of library object from `'\'''
libtool: compile: cannot determine name of library object from `'

for vim:
$ ./configure
configure: error: can not find sources in auto or ..

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. use for-loop without "in WORDS ..."
2. cry
Actual results:
every parameter ("$@") is ignored

Expected results:
not ignoring, like older versions of bash (working as documented by the help)

Additional info:
I saw similar bug at debian bug tracking database some weeks/months ago

Comment 1 Tim Waugh 2002-12-15 17:12:56 UTC
With 2.05b-5 as shipped?  Can't reproduce that, sorry.  Perhaps you've
recompiled the package and used an alpha release of bison?

Comment 2 Sami Farin 2002-12-15 17:21:14 UTC
yes..  I recompiled it (I needed the utf8 patches etc & I don't have newer glibc
as in RH8).

I happen to be running bison-1.75, it's from ftp://ftp.gnu.org/pub/gnu/bison/
if that version is buggy, maybe you could tell bug-bison@gnu.org about it..
or add check for bison version into bash configure script.

what bison version should work, by the way?

Comment 3 Tim Waugh 2002-12-15 18:09:54 UTC
The one we actually shipped with the release. :-)

Comment 4 Sami Farin 2002-12-16 00:24:37 UTC
after some hacking,  I found out what's the problem...
with bison-1.50 - 1.75, after "bison -d -y parse.y", y.tab.c contains

{ yyval.command = make_for_command (yyvsp[-4].word, add_string_to_list ("\"\"",
(WORD_LIST *)NULL), yyvsp[-1].command); }

instead of the expected result

{ yyval.command = make_for_command (yyvsp[-4].word, add_string_to_list
("\"$@\"", (WORD_LIST *)NULL), yyvsp[-1].command); }

1.75 removed $@ !
escaping @ ("\"$\@\"") would be the workaround for this bug with v1.75...

I just installed the latest alpha versio, 1.75d, it works fine...
both for_command and select_command work.

finally, sorry for bothering, but at first I didn't guess this is bison-related.