Re: env behavior incorrect

[Paul Jarc]

Jens Elkner <address@hidden> wrote:
> unfortunately env is not POSIX, or to be more specific, not "The Open Group
> Base Specifications Issue 6 IEEE Std 1003.1, 2003 Edition" compliant on Linux.
> (see http://www.unix-systems.org/version3/iso_std.html )
>
> E.g.: filename.env
> #!/usr/bin/env -i command args ...
>
> should exec command with the specified args with an empty env.
>
> However, env tries to execute $aPath/'-i command args ...', which usually
> fails or at least executes a non-intended command.

That's the kernel's doing, not env's.  The standard allows this
behavior; scripts are limited to only one argument in the "#!" line
after the interpreter.  Some kernels pass everything as one argument;
some split at spaces and pass multiple arguments; some split as spaces
and pass only the first.

> Since the kernel people do not wanna fix that creepy implementation, env 
> should
> 1) create a new char argv1[] and
> 2) resolve argv[1] into argv1[]
> 3) prepend argv1[] with argv[0]
> 4) append argv[2] to argv1[]
> 5) use argv1[] to check for opts and pass it to command, if a command was
>    specified

You mean split argv[1] at spaces?  No, that would violate the
standard.  It would break usage like this:
env foo="bar baz=quux" nextcommand...
env's behavior should not be changed.

> Furthermore according to XBD Utility Syntax Guidelines, long option support
> (i.e. --ignore-environment,  --unset) should be dropped.

I see wording about short options, but I see nothing discouraging
providing long options as well.

> Last but not least - why not
>     ...
>     static char *pointer2null = NULL;
>     ...
>     main(....) {
>       ...
>       if (ignore_environment)
>           environ = &pointer2null;

I haven't looked at the code, but I know that environ's type is not
char*, and it is not supposed to be NULL when the environment is
empty.


paul