Chet Ramey <chet.ramey@case.edu> wrote, on 30 Jun 2009:
>
> What should the shell do with environment strings that are not valid
> shell assignment statements? The question came up about environment
> variable names containing characters outside the set permissible for
> shell variable names, but it could also apply to environment strings
> like `a' or `=a'.
>
> For instance, what should the following print?
>
> env foo@bar=baz sh -c 'export | grep "^foo@" ; echo between; printenv |
> grep "^foo@"'
There are three parts to this:
1. What does env do with the argument "foo@bar=baz"?
As far as I can see the standard does not place any restriction on
the name part of the argument, so I think env must place the string
"foo@bar=baz" in the environment it passes to sh.
2. What does sh do with the string "foo@bar=baz" in the
environment during the initial assignment of variables?
XCU 2.5.3 says:
Variables shall be initialized from the environment (as defined
by XBD Chapter 8 (on page 173) and the exec function in the System
Interfaces volume of POSIX.1-2008) and can be given new values
with variable assignment commands. If a variable is initialized
from the environment, it shall be marked for export immediately;
see the export special built-in.
XBD 8.1 says:
Environment variable names used by the utilities in the Shell and
Utilities volume of POSIX.1-2008 consist solely of uppercase
letters, digits, and the <underscore> ('_') from the characters
defined in Table 6-1 (on page 125) and do not begin with a digit.
Other characters may be permitted by an implementation;
applications shall tolerate the presence of such names.
and XCU 2.5 says:
A parameter can be denoted by a name, a number, or one of the
special characters listed in Section 2.5.2 (on page 2302). A
variable is a parameter denoted by a name.
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.
Since 8.1 implies the shell does not "use" environment variables
with bad names, and 2.5 requires shell variables to have "good"
names, I think it is clear that the shell must not initialize
shell variables from environment variables with bad names.
3. Does sh include the string "foo@bar=baz" in the environment
it passes to printenv?
There seems to be a nasty defect in the standard here. XCU
2.9.1.1 Command Search and Execution says (in item 1.d.i.b):
... the shell executes the utility in a separate utility
environment (see Section 2.12, on page 2331) with actions
equivalent to calling the execve() function as defined in the
System Interfaces volume of POSIX.1-2008 with the path argument
set to the pathname resulting from the search, arg0 set to the
command name, and the remaining arguments set to the operands,
if any.
This refers to execve(), but the description of what is passed
to it matches the arguments for execl(), not execve(). It also
requires only the _operands_ to be passed, omitting any options
(and the -- delimiter if present)! This defect goes all the way
back to POSIX.2-1992. (Item 2 in the same section also has the
same problems.)
Bringing it back to the point at hand, the above quote says
nothing about the environment passed to the executed utility,
so when we fix that whole paragraph we can choose what
requirement we want to make. Presumably we will want it to
allow both existing behaviours.
--
Geoff Clare <g.clare@opengroup.org>
The Open Group, Thames Tower, Station Road, Reading, RG1 1LX, England
|