Bug 79626 - for is seriously broken
Summary: for is seriously broken
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: bash
Version: 8.0
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Tim Waugh
QA Contact: Ben Levenson
URL:
Whiteboard: bug in for_command and select_command...
Depends On:
Blocks:
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:
Environment:
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 fortest1.sh 
#!/bin/bash1
for x
  do echo foo "${x}"
done

$ cat fortesta.sh 
#!/bin/bash-2.05a
for x
  do echo foo "${x}"
done

$ cat fortestb.sh 
#!/bin/bash-2.05b
for x
  do echo foo "${x}"
done

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

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):
2.05b-5

How reproducible:
100.000%

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.



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