Re: env behavior incorrect

[Jens Elkner]

'Paul Jarc wrote:'
> 
> 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;

OK.

> scripts are limited to only one argument in the "#!" line
> after the interpreter.

Hmm, have you any pointer to a guideline or standard for this. Currently
I have not found anything wrt. #! interpreter arg, expect in the Solaris
exec manpage :(

> Some kernels pass everything as one argument;
> some split at spaces and pass multiple arguments; some split as spaces
> and pass only the first.

OK. Than IMHO a note should be addded to the man page, that usage of
--x--
#! /usr/bin/env [OPTION]... [-] [NAME=VALUE]... [COMMAND [ARG]...]
--x--
is not portable and therefore should not be used.
  
> > 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.

Ooops. I forgot to think about that :((((
  
> > 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.

Well, probably depends on the point of view. Utility Syntax Guidelines -
Guideline 3 says:
"
Each option name should be a single alphanumeric character (the alnum character 
classification) from the portable character set. The -W (capital-W) option 
shall be reserved for vendor options.

Multi-digit options should not be allowed.
"

So IMHO '-ignore-environment' and '-unset' are more than a single character ...
Of course, it is not discouraged, but at least in does not obey the mentioned
Guideline....
  
> > 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.

Well, pointer art I guess ;-). &pointer2null is not NULL and a (char **) ...
But don't break your head, its just a minor optimization ...

Regards,
jens.
-- 
+---[ Jens Elkner ]---------[ IMS GmbH, Abt. Server/Netzwerkmanagement ]--+
| Sandtorstr. 23                       +49 391 54486 19230                |
| 39106 Magdeburg                       address@hidden                |
| GERMANY                             http://www.imsgroup.de/             |
+-------------------------------------------------------------------------+