#234 env is broken

[eliz]

The env program from the latest port of CoreUtils 5.2.1-1
is broken as far as environment modifications are
concerned. Observe (my comments inside brackets):

D:\usr\eli>set FOO=bar [define a variable]

D:\usr\eli>set FOO [verify it is defined]
FOO=bar [ok, it's there]

D:\usr\eli>env -u FOO env | grep -F FOO [try undefining]
FOO=bar [nope, it's still there]

D:\usr\eli>env -u FOO cmd

D:\usr\eli>Microsoft Windows XP [Version 5.2.2600]
(C) Copyright 1985-2001 Microsoft Corp. [so far so good]

D:\usr\eli>set FOO
FOO=bar [-u didn't work]

D:\usr\eli>exit
[no prompt, need Enter to exit]
[Enter]
D:\usr\eli> [exited]

D:\usr\eli>env BAR=baz env | grep -F BAR
[defining BAR didn't work]
D:\usr\eli>

==================================
Conclusions:

1) You cannot define, redefine or undefine a variable for a
process invoked by env.
2) If you invoke the shell, exiting the shell strangely
doesn't really exit until you press an extra Enter.

Another related problem is with variables that are defined
via the Control Panel: it's non-trivial for env to modify
them, but I think it should nevertheless try. This is
especially important when one uses "env -i".

[eliz]

Logged In: YES
user_id=1257325

In addition, "env -i" doesn't work as on Unix and GNU/Linux
systems. Here's what it does on Windows:

D:\usr\eli>env -i cmd
env: cmd: No such file or directory

On Unix, the equivalent command ("env -i sh") does not fail
like that, because there's a default search path in the
absence of the PATH variable. I think the Windows port
should behave similarly: it should at least look in
C:\WINDOWS\system32 and perhaps a bunch of other
standard places (which are actually Windows version
dependant).

[GnuWin]

Logged In: YES
user_id=217802

This bug has been fixed. A new release is available through
http://gnuwin32.sourceforge.net/