'Paul Jarc wrote:'
>
> Jens Elkner <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] |
| GERMANY http://www.imsgroup.de/ |
+-------------------------------------------------------------------------+
_______________________________________________
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils
