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) 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.) > 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. On my (somewhat outdated) Cygwin installation, cygpath seems to translate relative Windows paths to relative Cygwin paths. If I understand you correctly, the conversion done by cygpath is the same that Cygwin uses to translate the value of HOME before deciding whether the outcome is a valid POSIX path. Wouldn't this already detect a relative value of HOME as invalid? > 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? As I wrote above, a value for HOME might indeed be useful under Windows, IMHO. So I'd vote to follow the "principle of least surprise", which apparently would be to consider the (cygpath-) translated value of HOME instead of ignoring it too easily. Best regards, Horst -- Horst Kiehl, Institute of Bio- and Geosciences, IBG-1: Biotechnology Phone +49 2461 61-5131, Fax +49 2461 61-2231, E-Mail h.p.ki...@fz-juelich.de WWW http://www.fz-juelich.de/ibg/ibg-1/DE/Forschung/Infrastruktur/Elektronik_usw/_node.html -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Forschungszentrum Jülich GmbH 52425 Jülich Sitz der Gesellschaft: Jülich Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher Geschäftsführung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt
smime.p7s
Description: S/MIME cryptographic signature
