This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: [ANNOUNCEMENT] Updated: Cygwin 2.2.0-1


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.kiehl@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

Attachment: smime.p7s
Description: S/MIME cryptographic signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]