IFS=':' set -- aa:bb:cc:dd # Fails to set "$@"
Configuration Information [Automatically generated, do not change]: Machine: i386 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i386-redhat-linux-gnu' -DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -D_GNU_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables uname output: Linux saturn.syslang.net 2.6.27.41-170.2.117.fc10.i686.PAE #1 SMP Thu Dec 10 10:48:30 EST 2009 i686 athlon i386 GNU/Linux Machine Type: i386-redhat-linux-gnu Bash Version: 3.2 Patch Level: 39 Release Status: release Description: It may be me, but I tried something that I thought should work, but it does not. I want to use the set command to parse data and I want the IFS variable to be in force during the set command. This does not work. So far, every other use of var=val cmd seems to work fine. Only this one plays funny. Repeat-By: IFS=':' set -- aa:bb:cc:dd echo $1 # After this runs, $1 is aa:bb:cc:dd instead of aa Instead, I have to say something like: oldIFS="$IFS" IFS=':' set -- aa:bb:cc:dd IFS="$oldIFS" BTW, the same behavior happens in bash4. Fix: Offered in the constructive spirit to see if this needs to be fixed or if this is a deliberate or known behavior. TIA
typeset -r prevents local variable of same name.
Configuration Information [Automatically generated, do not change]:
Machine: i386
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i386-redhat-linux-gnu'
-DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL
-DHAVE_CONFIG_H -I. -I. -I./include -I./lib -D_GNU_SOURCE
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g -pipe -Wall
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic
-fasynchronous-unwind-tables
uname output: Linux saturn.syslang.net 2.6.27.41-170.2.117.fc10.i686.PAE #1 SMP
Thu Dec 10 10:48:30 EST 2009 i686 athlon i386 GNU/Linux
Machine Type: i386-redhat-linux-gnu
Bash Version: 3.2
Patch Level: 39
Release Status: release
Description:
First, I already submitted this bug from work, but I didn't
realize that the address I sent from would not be allowed to receive
a response. This address will work fine.
If I declare a variable at the top scope using -r, it will prevent me
from declaring a local copy in a subroutine. This problem happens in
this version of bash as well as in bash4 under Fedora 14.
Repeat-By:
Here is a foo.sh that demonstrates the problem:
511 > cat foo.sh
#! /bin/bash
bar()
{
typeset abc="$1"
echo "abc:$abc"
}
typeset -r abc='Hello'
bar Goodbye
512 > ./foo.sh
./foo.sh: line 4: typeset: abc: readonly variable
abc:Hello
513 >
Here's another one that works and shows that top scope is the problem:
515 > cat foo2.sh
#! /bin/bash
baz()
{
typeset qwerty="$1"
typeset -r abc=wahoo
echo "qwertyabc:$qwerty$abc"
}
bar()
{
typeset abc="$1"
echo "abc:$abc"
}
bar Goodbye
baz ttt
515 > ./foo2.sh
abc:Goodbye
qwertyabc:tttwahoo
516 >
This makes it hard to define routines with local variables if you
don't know what variables are declared globally. The problem happens
with -r but does not seem to happen with -i or -a.
Am I missing something?
TIA
Steven W. Orr
Fix:
[Description of how to fix the problem. If you don't know a
fix for the problem, don't include this section.]
