Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 79626 - for is seriously broken
Summary: for is seriously broken
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: bash
Version: 8.0
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Tim Waugh
QA Contact: Ben Levenson
Whiteboard: bug in for_command and select_command...
Depends On:
TreeView+ depends on / blocked
Reported: 2002-12-14 05:02 UTC by Sami Farin
Modified: 2005-10-31 22:00 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2002-12-15 18:09:54 UTC

Attachments (Terms of Use)

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 
for x
  do echo foo "${x}"

$ cat 
for x
  do echo foo "${x}"

$ cat 
for x
  do echo foo "${x}"

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

$ ./ works very well
foo works
foo very
foo well

$ ./ 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
if that version is buggy, maybe you could tell 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", 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.

Note You need to log in before you can comment on or make changes to this bug.