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

[William Park]

Thanks for heads up, Christian.  Filtering out "." will break our company's 
accounting software, and presumably many other applications.

Checking for correct charset is sensible thing to do when setting or accessing 
a variable.  But, those variables that Bash did not change or set, should be 
passed on to the next program untouched.

--William

--- On Fri, 6/26/09, Christian Krause <chkr@plauener.de> wrote:

> From: Christian Krause <chkr@plauener.de>
> Subject: Re: bash 4.x filters out environmental variables containing a dot in 
> the name
> To: chet.ramey@case.edu
> Cc: bug-bash@gnu.org
> Received: Friday, June 26, 2009, 7:58 AM
> 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
> 
> 
> 


      __________________________________________________________________
Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your 
favourite sites. Download it now
http://ca.toolbar.yahoo.com.