Email List: Xaustin-group-lX
[All Lists]

Re: Invalid shell assignments in environment

To: austin-group-l@xxxxxxxxxxxxx, gwc@xxxxxxxxxxxxx
Subject: Re: Invalid shell assignments in environment
From: Glenn Fowler <gsf@xxxxxxxxxxxxxxxx>
Date: Thu, 2 Jul 2009 11:04:57 -0400
Organization: AT&T Research
References: <200907012242.n61MgCCp020103@penguin.research.att.com> <4A4C2005.6030402@case.edu> <4a4c81a6.2tWl4Z9DpJUyvd+z%Joerg.Schilling@fokus.fraunhofer.de> <200907021327.n62DRe5k029384@penguin.research.att.com> <20090702143325.GA5491@squonk.masqnet>
thanks

the variable name was
        gl<u-umlaut>ck
also, using sh as the parent application was not a good choice

assume that the parent process supports UTF-8 chars in the environment

should a child sh of the parent process, child in the C locale,
be able to prevent a grandchild process, grandchild in a UTF-8 locale,
from seeing those UTF-8 environment variables?

On Thu, 2 Jul 2009 15:33:25 +0100 Geoff Clare wrote:
> Glenn Fowler <gsf@research.att.com> wrote, on 02 Jul 2009:
> >
> > what about this scenario
> > 
> > in UTF-8 locale parent shell:
> > glC<ck=bad
> > export glC<ck

> [Looks like your UTF-8 character got munged somewhere.  I'm assuming
> the C< was supposed to be a u-umlaut character.]

> The shell should complain about the variable name.  Quoting from
> my first mail in this thread:

> | There is a formal definition for "name" in this context:
> | 
> |     3.230 Name
> |     In the shell command language, a word consisting solely of
> |     underscores, digits, and alphabetics from the portable character
> |     set. The first character of a name is not a digit.

> Note the phrase "from the portable character set".  Thus u-umlaut
> is not a valid character in shell variable names.

<Prev in Thread] Current Thread [Next in Thread>