environment setup problem with "env -"

[Pierre A. Humblet]

Christopher Faylor wrote:
> 
> On Mon, Jan 12, 2004 at 03:20:38PM -0500, Joe Buehler wrote:
> >Igor Pechtchanski wrote:
> >>FWIW, here's what I get on my machine:
> >>$ env - /bin/env
> >>HOMEDRIVE=C:
> >>HOMEPATH=\
> >>LOGONSERVER=\\PECHTCHA
> >>SYSTEMDRIVE=C:
> >>SYSTEMROOT=C:\WINNT
> >>USERDOMAIN=PECHTCHA
> >>USERNAME=igor
> >>USERPROFILE=C:\Documents and Settings\igor
> >>$
> >
> >The one that caused me grief was USERPROFILE.  It caused trouble
> >because of a 3rd party tool that did not expect any spaces in
> >its value.  I was a little surprised at first because I am using
> >env for strict control of the environment.

Instead of using env, set USERPROFILE to something with no space.

> >If they have to stay because Microsoft says so, I guess I'll have
> >to work around this some other way.
> 
> Maybe Corinna or Pierre can chime in here.  I don't remember the
> unfortunate details which made us decide to keep those around.  Or,
> maybe this is actually a bug.

It's a "one thing led to another" situation.
1) Windows programs expect those variables.
2) They are user dependent and must be changed following a setuid.
3) Due to a Windows quirk, some of the computation must be done *before*
   exec'ing the program following a setuid. That eventually led to
   generating the stuff on the fly and storing it in the cygheap.
4) If they don't exist in the current environment, they are only
   produced when exec'ing potential Windows programs (see mount -X) 

Given 1) and the effort made in 4), we can argue forever whether it's
a bug. An alternative would be to only regenerate these variables
following a setuid. I vaguely recall doing that at some point.

Pierre