On Thu, Feb 17, 2011 at 11:13 AM, Chet Ramey <chet.ra...@case.edu> wrote:
> On 2/13/11 3:17 PM, ste...@syslang.net wrote: > > 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. > > This is intentional. A variable is declared readonly for a reason, and > readonly variables may not be assigned to. I don't believe that you > should be able to use a function to circumvent this. > > That makes little sense to me. I don't see any disadvantages if a local var is allowed to use the same name as a global readonly var. And with current bash behavior we may see var name collisions even with the local keyword. > Chet > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, ITS, CWRU c...@case.edu > http://cnswww.cns.cwru.edu/~chet/ > > -- Clark
