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

[Stephane CHAZELAS]

2009-06-29, 10:03(-04), Chet Ramey:
>
>> and it's a bug that bash-4 is filtering them.
>
> Maybe, maybe not.  That's open to interpretation.  Here's how I see it.
>
>> 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.
>
> The shell is not like other applications that simply pass the environment
> through as uninterpreted strings.  It applies semantic interpretation to
> the environment variables it inherits.

Many tools that use the environment apply semantic
interpretation to the environment variables they inherit, and
what variable is supported by a shell is shell dependant.

> Shells scan the initial environment exactly once: at startup, when creating
> variables.  The environment passed to child processes is created from the
> set of exported shell variables.  This implies to me that the environment
> passed to child processes consists only of valid shell variables.

For the rc or es shell, anything is valid except the empty string.

> Certainly conforming applications should not create environment variables
> with invalid names.

What about non-conforming applications? I agree that if they
should to use the shell API, they should conform to it, but
here, we're in case not covered by the API. That application
should be able to expect its environment to be transfered as is
through a shell to another non-conforming application.

>> 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.
>
> Posix also says that "variables" are inherited from the environment.  That
> word has a very specific meaning, as was reiterated during the $@ and set -u
> discussion.  The same "variables" language is used when Posix talks about
> creating the environment for shell execution environments.

Yes, but that's shell variables, it's not talking about the rest
of the environment.

> The question is whether "tolerant" just means that the shell doesn't display
> a warning message about the assignment, as it does when you use an invalid
> variable name in an assignment statement, or exit with a variable assignment
> error, or dump core with a seg fault, as in many historical versions of sh.
> It may or may not also mean that the shell passes inherited invalid variable
> names to child processes.
>
> Historical versions of sh and ksh behave like bash-4.0.

ksh93 doesn't but pdksh/mksh still does.

> It seems, though, that there might be enough use for me to try and make it
> work.  While I'm not wild about creating yet another class of variable,
> there might be a way to do it simply.

I suppose the most obvious way would be to store away those
environment strings that bash doesn't know how to handle and
append it to each execve.

Now other points to consider could be what to do in cases like:
  - there is both a=1 and a=2 in the environment passed to the
  shell.
  - there is both "a=1" and "a" in the environment passed to the
  shell. (and maybe also "" and "=x").

I think it's probably worth asking the Austin group about it.

-- 
Stéphane