Re: bash 4.x filters out environmental variables containing a dot in the name

[Christian Krause]

Hi Chet,

Thanks for the answers. The problem is now, that this behavior of the
bash creates some real problems outside, probably with a larger impact.
Before asking the kernel developers to change parts of linux kernel's
build system, I'd like to be sure whether bash-4.x's behavior is correct
or not. Please see my comments below:

Chet Ramey wrote:
> 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

As far as I interpret the standard (IEEE Std 1003.1, 2004 Edition), the
general definition for environment variables is something like this:

- names must not contain "="
- if it should be portable, the names should only contain characters
from the portable character set (which includes ".")

Sure, there is a restriction that variables used by the shell (and the
utilities described in the standard) should only contain the characters
 you described.

However, since not all programs belong to this set, I don't see an
explicit statement which denies the usage of e.g. "." in environmental
variables in general.

> 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.

Hm, I'm not sure I can agree to this. The problem is, that for other
programs names of environmental variables containing a "." are not
invalid (although they are invalid for the bash).

As far as I understand the behavior of the bash, environmental variables
which were put in the process environmental during exec'ing a shell are
exported to subsequent processes of this shell without explicitly
"exporting" them.
So, if the bash passes variables containing in the bash's process
environment to sub-processes anyway (without any explicit "export"), I
would argue it would be more natural that the bash should not filter
them. If any other process execs itself, the new process image will have
the same environmental variables set (if not execle is used)...

Given all of these facts I still tend to say that the bash shouldn't
filter them...


Best regards,
Christian