Christian Krause 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=i586 -mtune=generic > -fasynchronous-unwind-tables > uname output: Linux noname 2.6.29.4-167.fc11.i686.PAE #1 SMP Wed May 27 > 17:28:22 EDT 2009 i686 i686 i386 GNU/Linux > Machine Type: i386-redhat-linux-gnu > > Bash Version: 4.0 > Patch Level: 16 > Release Status: release > > Description: > During the compilation of the linux kernel (configured to user mode > linux) I've discovered the following problem of bash 4.0 (which is now > delivered by Fedora 11): > > If an environmental variable contains a "." in its name, the new bash > 4.0 filters out these variables. They will not be visible via "set" nor > will they be inherited to executed sub-shells or processes.
Such strings are invalid shell or environment variable names. It was a bug in bash-3.2 that it created invalid variables from the initial environment. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Chet Ramey, ITS, CWRU c...@case.edu http://cnswww.cns.cwru.edu/~chet/
