Corinna Vinschen
Mon Jul 1 00:44:00 GMT 2002

On Sun, Jun 30, 2002 at 11:57:32PM -0400, Chris Faylor wrote:
> On Sun, Jun 30, 2002 at 11:56:40AM +0200, Corinna Vinschen wrote:
> >- If in evironment, done.
> >- Else ask /etc/passwd
> >- Else use environemt vars HOMEDRIVE/HOMEPATH.
> >
> >The server is only asked for getting HOMEDRIVE/HOMEPATH and
> >the values are never used to set the environment or to
> >evaluate HOME.  So if HOMEDRIVE/HOMEPATH are missing in the
> >environment, getting the values from the server doesn't help
> >for setting HOME.  Or do I miss something?
> Nope, you aren't missing anything.  When I reworked that logic, I
> thought about using the derived values of HOMEPATH/HOMEDRIVE but that
> would mean a potentially expensive operation, right?  Maybe it doesn't

> So, I just added the potential capability to set HOME from
> HOMEPATH/HOMEDRIVE.  It isn't on yet, though.


> Boy, I think I hate these environment variables almost as much as I hate
> Windows 95.  Have I mentioned that lately?

Not this month...

> Oh, and currently I made HOME default to / if it can't figure out
> anything else.  Does that make sense?

That's ok but I'm still sure it makes sense to use HOMEDRIVE/HOMEPATH
first.  Setting to "/" should be just the last fallback.  

What's the problem in trusting these environment variables?  The user
could change them, yes, but the user can change a lot of stuff.  The user
could also change $HOME to some bogus value and in case of $HOME it's
suddenly no problem to trust the environment but for HOMEDRIVE/HOMEPATH
it is?  Sounds not logical to me.

In contrast to your solution I'd add another getenv("HOMEDRIVE")/
getenv("HOMEPATH") to evaluate homedrive/homepath.  This would very
likely eliminate another potential server call.  Currently it's

- Get from /etc/passwd
- Else get from server

What I think is better is

- Get from /etc/passwd
- Else use environemt vars HOMEDRIVE/HOMEPATH (as for HOME)
- Else get from server


Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                      
Red Hat, Inc.

More information about the Cygwin-developers mailing list