Greetings, Kiehl, Horst! > Corinna Vinschen wrote:
>> 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 > The second case, IMHO, *is* an absolute path in the context of Windows: > C:/foo > So my assumption as a user would be that Cygwin would use this value for > HOME in its (cygpath-) translated form: /cygdrive/c/foo > This way I could continue to use my Windows profile directory > (%USERPROFILE%) as my Cygwin home directory (with the definition of > HOME=%USERPROFILE% and the symbolic link /home -> cygdrive/c/Users to > keep ssh working) Use fstab ? C:/Users /home bind noacl,binary,exec,posix=0 0 0 > as well as e.g. continue to use the Windows port of > GNU Emacs which consults the HOME variable too. > In other words, if Cygwin would continue to use HOME=/cygdrive/c/foo as > the conversion of HOME=C:/foo, this would follow the principle of least > surprise, IMHO. > (Just thinking ... would even the third case (HOME=//foo/bar) be a valid > scenario? Does Cygwin "technically allow" the home directory to be on > the network? If there is a POSIX-compliant translation of //foo/bar, it > might be a better choice than ignoring the value.) Technically, there's no restriction. And I can imagine an AD environment, where it is actually desirable to have it on the network. -- With best regards, Andrey Repin Wednesday, August 5, 2015 19:43:02 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
