bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: env -u behavior


From: Eric Blake
Subject: Re: env -u behavior
Date: Sat, 24 Oct 2009 08:03:09 -0600
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Mike Frysinger on 10/24/2009 12:16 AM:
> On Friday 23 October 2009 16:33:01 Eric Blake wrote:
>> Eric Blake <ebb9 <at> byu.net> writes:
>>> Is 'env -i -u a=b' really supposed to output a=b, or should it be an
>>> error (because a=b is not a valid environment name)?  Right now, it is
>>> the former, because we are using putenv() to remove variables from
>>> environ, rather than unsetenv().  Similarly, should env -u '' issue an
>>> error?
>> Also, if I'm reading POSIX correctly,
>>
>> env -- a=b true
>>
>> is supposed to execute true with a=b in the environment, rather than GNU
>> behavior of executing ./a=b (POSIX says to use 'env ./a=b true' to get
>>  similar behavior).
> 
> eh ?  my installed coreutils-7.6 (as well as a quick test of 8.0) does the 
> right thing according to POSIX -- it sets "a" to "b" and executes `true`.

There's still something weird going on.  I saw this on cygwin 1.5, which
uses gnulib's getopt (starting without . in my PATH):

$ echo 'echo one' > ./c=d
$ echo 'echo two' > ./--
$ chmod +x ./c=d ./--
$ env c=d echo three
three
$ env -- c=d echo three
three
$ PATH=:$PATH env -- c=d echo three
three
$ env a=b -- c=d echo three
one

Huh?  ./-- is not on my PATH, why was it executed?

$ PATH=:$PATH env a=b -- c=d echo three
two

Huh?  This should have executed ./--, not ./c=d.

Also, I was going off the comments in env.c:

>    env -u EDITOR LOGNAME=foo PATH=/energy -- e=mc2 bar baz
>         runs the program "/energy/e=mc2" with environment
>         { LOGNAME=foo PATH=/energy }

I'm investigating what to do to patch things.  I'm al

Maybe it's worth the invention of a new option to inform env which program
to invoke.  Something like:
env a=b --program c=d e=f
invoking ./c=d with argv[1] of e=f and environ of a=b.  Then again, no one
has really complained - program names containing = are not portable, so
not really much of an issue in practice.

Or, we could just document a workaround:

env a=b command c=d e=f
env a=b sh -c 'c=d e=f'

(The latter is more portable, even though it requires more quoting: POSIX
says command must be available via PATH, since it is not a shell special
built-in, but some systems, like cygwin, don't do this yet).

- --
Don't work too hard, make some time for fun as well!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkrjCR0ACgkQ84KuGfSFAYCWcQCg0eTsNNPUgs0elfDmRXvXs5Qr
IrwAoJkJ8fbFrtFMKbzSXZijOXNBMAqU
=zj0G
-----END PGP SIGNATURE-----




reply via email to

[Prev in Thread] Current Thread [Next in Thread]