bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Chet Ramey
Subject: Re: bash 4.x filters out environmental variables containing a dot in the name
Date: Mon, 29 Jun 2009 10:03:45 -0400

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

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.

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

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

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.

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.

Chet


-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer

Chet Ramey, ITS, CWRU    chet@case.edu    http://tiswww.tis.case.edu/~chet/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]