Re: env -u behavior

[Mike Frysinger]

On Saturday 24 October 2009 08:28:01 Eric Blake wrote:
> According to Mike Frysinger on 10/24/2009 12:11 AM:
> > On Friday 23 October 2009 14:44:03 Eric Blake wrote:
> >> 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?
> >
> > i dont think these things should error as there's no actual limitation in
> > the coreutils code to do so (and POSIX allows this behavior).  the code
> > should call unsetenv() on whatever the user gives it.  so in these two
> > cases, it should do:
> >     unsetenv("a=b");
> 
> Which is required to fail.

which is fine

> But right now we call putenv("a=b"), which puts "a=b" into the environment
> instead of unsetting "a".

which is not fine

> >     unsetenv("");
> 
> Which is required to fail.  But right now we call putenv(""), which is a
> silent no-op.

that sounds no good to me

> > same goes for setting invalid env vars like:
> >     env foo.cow=moo some-cmd
> > the env program should call:
> >     setenv("foo.cow", "moo", 1);
> >
> > the only error that should be emitted is if the underlying unsetenv() or
> > setenv() functions fail
> 
> But that's my point - we aren't calling unsetenv().  Should we be?

i think so.  if env is told to unset something, we should unset what we're 
told instead of trying to parse and guess at the user intention (or in this 
guess, do the completely wrong thing).

while the -u option isnt covered in POSIX, typically the POSIX/UNIX behavior 
is "do what you're told and nothing more" and follows the idea of "least 
surprise".  this behavior you raise seems to violate both points.
-mike

signature.asc
Description: This is a digitally signed message part.