On Aug 4 20:53, Achim Gratz wrote: > Warren Young writes: > > Here’s an interesting experiment to try on your non-Cygwin POSIX boxes: > > > > $ HOME=/dfjkshkds bash -l > > $ echo $HOME > > > > Guess what it prints. > > > > Hint: It isn’t the second-to-last field in /etc/passwd. :)
This is correct behaviour, of course. > > Spoiler: Apparently Cygwin is already doing the standard thing. No, it's not. Or, to phrase it a bit differently, it doesn't perform thr action it was supposed to do. My testing seemed to be a teeny bit half-hearted... The problem the fix was *supposed* to fix (but it didn't) was to disallow incoming $HOME values which are non-POSIX or non-absolute paths. These $HOME values should be disregarded. So the idea was: set HOME=foo <- ignored, set HOME from passwd DB entry set HOME=C:/foo <- same set HOME=//foo/bar <- same set HOME=/foo/bar <- valid, taken Right now, when started from a non-Cygwin process, Cygwin takes the value of $HOME and simply calls the Win32->POSIX conversion function. It does so for a long time, but is that right? Especially if %HOME% is a non-absolute == relative path, the resulting POSIX value of $HOME depends on the current directory when starting Cygwin. This sounds like a terrible idea to me. Together with cases like https://cygwin.com/ml/cygwin/2015-07/msg00344.html, and the fact that $HOME has no meaning in native Windows (HOMEPATH/HOMEDRIVE instead) I'm inclined to think that any incoming $HOME should make sense from a POSIX POV, otherwise we take the value from the passwd DB as defined by /etc/nsswitch.conf. Does anybody have a *good* reason *not* to change this? > That's why I offered to ignore the issue. That also needs nothing to be > done by me, which is an added benefit. :-) That may be the way to go as soon as Cygwin is doing the right thing :} Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
pgptQrhCyS1pf.pgp
Description: PGP signature
