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


On Aug  5 09:19, Kiehl, Horst wrote:
> 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.

You can do this anyway by using a matching definition in /etc/nsswitch.conf
(https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping-nsswitch), e.g.:

  db_home: %H

> 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.)

That was a typo, sorry.  I was using slashes instead of backslashes
by habit.  //server/share is a valid POSIX path.  \\server\share isn't.

> > 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?

In theory, but not as you describe above.  cygpath has a -a switch.
This functionality is used to convert $HOME.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

Attachment: pgptKH_JeCAgO.pgp
Description: PGP signature


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