[Top][All Lists]
[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-----
- env -u behavior, Eric Blake, 2009/10/23
- Re: env -u behavior, Mike Frysinger, 2009/10/24
- Re: env -u behavior, Eric Blake, 2009/10/24
- Re: env -u behavior, Mike Frysinger, 2009/10/25
- Re: env -u behavior, Eric Blake, 2009/10/26
- Re: env -u behavior, Mike Frysinger, 2009/10/26
- Re: env -u behavior, Eric Blake, 2009/10/26
- Re: env -u behavior, Jim Meyering, 2009/10/26