Bug 79626 - for is seriously broken
for is seriously broken
Status: CLOSED WORKSFORME
Product: Red Hat Linux
Classification: Retired
Component: bash (Show other bugs)
8.0
All Linux
low Severity low
: ---
: ---
Assigned To: Tim Waugh
Ben Levenson
bug in for_command and select_command...
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-12-14 00:02 EST by Sami Farin
Modified: 2005-10-31 17:00 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-12-15 13:09:54 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Sami Farin 2002-12-14 00:02:30 EST
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 12:12:56 EST
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 12:21:14 EST
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 13:09:54 EST
The one we actually shipped with the release. :-)
Comment 4 Sami Farin 2002-12-15 19:24:37 EST
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.