Several scripts are attempting to initialise variables using 'var=()' which generates syntax errors e.g. # rc-status /lib/rcscripts/sh/rc-daemon.sh: line 328: syntax error near unexpected token `(' /lib/rcscripts/sh/rc-daemon.sh: line 328: ` local -a RC_DAEMONS=() RC_PIDFILES=()' /bin/rc-status: line 167: update_service_status: command not found /bin/rc-status: line 167: update_service_status: command not found /bin/rc-status: line 167: update_service_status: command not found [snip] This causes many of the init scripts to fail, resulting in broken net configurations etc. I believe these initialisations should be 'var=""'. The affected scripts that I've found so far are: /etc/init.d/net.eth0 /etc/init.d/runscript.sh /lib64/rcscripts/net.modules.d/iwconfig /lib64/rcscripts/sh/rc-daemon.sh
Addendum - for 32-bit platforms, substitute /lib/rcscripts for /lib64/rcscripts.
After trying to rollback to earlier versions of baselayout, it appears the problem is caused by bash-3.1; masking this and re-emerging bash-3.0 fixes the scripts. (While simply changing the variable initialisation removed the syntax error messages, the scripts didn't work properly e.g. /etc/init.d/net.lo attempts to use DHCP, and fails.)
*** Bug 115150 has been marked as a duplicate of this bug. ***
Problem and workaround confirmed here on gentoo 2.4 / athlon xp. Note that the version number is actually bash-3.0-r14.
Initialisations are correct; it's a parsing error with two or more array variables declared in the same statement. Splitting the array initialisations onto one per line is a workaround.
*** Bug 115187 has been marked as a duplicate of this bug. ***
bash-3.1 is in package.mask now...
hum, same here? #/etc/init.d/iptables restart /lib/rcscripts/sh/rc-daemon.sh: line 328: syntax error near unexpected token `(' /lib/rcscripts/sh/rc-daemon.sh: line 328: ` local -a RC_DAEMONS=() RC_PIDFILES=()'
(In reply to comment #8) > hum, same here? Hum, there's really no need to post 'me too' comments. Downgrade your bash.
works: func() { local -a foo=() ; } fails: func() { local -a foo=() bar=() ; }
So this has nothing to do with baselayout, that was just a coincidence. Good the bug tile has been modified to clarify this. About bash 3.1: I guess this behaviour is intentional? Will all offending scripts be rewritten?
There is no indication in the bash man page that multiple assignments of arrays are forbidden, and, indeed, this is the case... Following on from comment #10: func() { local -a foo=() bar=(1); } works. Fairly obviously a (upstream?) bug. Then again, I'm not sure why the variables are being initialised to () anyway. Doesn't seem necessary since "local -a foo bar" would have the same effect. Phil
> func() { local -a foo=() bar=(1); } > > works. Fairly obviously a (upstream?) bug. that doesnt work, sounds like you downgraded to bash-3.0 and then ran the test
*** Bug 115257 has been marked as a duplicate of this bug. ***
Bash 3.0 behavior: foo() { local -a BAR=() BAR1=(); } -- Works foo() { local BAR= BAR1=; } -- Works Bash 3.1 behavior: foo() { local -a BAR=() BAR1=(); } -- Error: bash: syntax error near unexpected token `(' foo() { local BAR= BAR1=; } -- Works So bash 3.1 is treating -a differently. When creating local arrays it doesn't allow more than one declaration on a line. When creating just local variables you can create more than one on a line in both versions. I'm not convinced it's an upstream bug. There is an obvious difference, but it may be the intended behavior is to only allow one array to be declared at a time. The documentation needs to be cleared up on this issue.
the documentation is actually pretty clear local [option] [name[=value] ...] For each argument, a local variable named name is created, and assigned value. The option can be any of the options accepted by declare. and under declare we read: -a Each name is an array variable (see Arrays above). so the documentation *clearly* states that defining multiple arrays (i.e. using the -a option) is acceptable
Hi, Chet finally released a patch: ftp://ftp.cwru.edu/pub/bash/bash-3.1-patches/bash31-001 Tried it with an ebuild in my overlay and the problem is gone. Cheers Poly
thanks, bash-3.1-r1 in portage
But even with patch bash-3.1 doesn't read the configuration of the net interface. I have eth0 with hard configured ip, netmask and so, and when i start the iface it says that no configuration is available and assumes dhcp. It behaves just like /etc/conf.c/net.eth0 didn't exist or was empty.
Even worse, it breaks a lot of startup-scripts to (but without "noise" this time) and was therefor pulled back, obviously
