Mike Frysinger wrote:
> On Thursday 25 June 2009 19:17:38 Chet Ramey wrote:
>> Christian Krause wrote:
>>> 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.
>
> and it's a bug that bash-4 is filtering them. not allowing them to be used
> in
> the shell is fine (echo ${vmlinux.lds}), but removing them from the
> environment and thus not allowing other applications to leverage them is not.
>
It's not a bug. Posix explicitly restricts environment variable names
to consist of uppercase letters, lowercase letters, digits, and
underscores. There is no provision for variables with invalid names
that don't exactly exist and are just passed down to applications in
their environment. The environment is constructed from variables with
the export attribute set (another thing Posix explicitly states); things
that aren't valid variables don't get in there.
> POSIX explicitly states that applications shall tolerate the presence of
> these
> environment variables, and while that is open for interpretation (i.e. you've
> interpreted this to mean automatic removal), i dont see any reason for bash
> to
> be culling these.
That doesn't mean what you think it means. It means that applications
won't abort because of invalid names in the environment, like most
historical versions of sh.
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/
