2009-07-01 11:43:43 +0100, Geoff Clare:
[...]
> 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.
[...]
Some other way to put it could be can an application expect that
in doing in part1:
execve("/bin/sh", ["sh", "-c", "part2"], ["a.b=c"])
"a.b=c" will be passed in the environment of "part2". If we all
both behaviors, then the answer to the previous question is
"no" (which in practice is what happens today).
Other points to consider:
execve("/bin/sh", ["sh", "-c", "part2"], ["a=1", "a=2"])
and
execve("/bin/sh", ["sh", "-c", "a=3; part2"], ["a=1", "a=2"])
This little program:
int main(int argc, char **argv) {
char *e[] = { "x", "=", ".=", "1=", "", "a=1", "a=2", "b=1", "b" , 0 };
execve("/usr/bin/env", argv, e);
}
gives all sorts of different interesting behaviors when invoked as:
this-prg <shell> -c env
or
this-prg <shell> -c 'echo $a'
or
this-prg <shell> -c 'a=3; env'
Some shells strip all the /invalid/ variables (like pdksh,
bash4, older ksh), others only some (like bash3, ksh93s, dash).
Some will set a to 1, others to 2...
regards,
Stephane
|