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 05.08.2015 12:12, Corinna Vinschen wrote:
On Aug  5 11:09, Thomas Wolff wrote:
Am 05.08.2015 um 09:54 schrieb Corinna Vinschen:
So the idea was:

   set HOME=foo		<- ignored, set HOME from passwd DB entry
   set HOME=C:/foo	<- same
No, please don't!
   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.
Other POSIX systems don't handle this situation well either, so I don't see
a need to act here.
Other POSIX systems don't usually get a broken path.  The path is set
by the login process with the value taken from the passwd DB.  That's
what should be the default for Cygwin processes started from non-Cygwin
processes as well.  Of course Cygwin has to use $HOME because it could
be set for a reason.  But typically we don't need $HOME from Win32
processes, unless it's propagated from another Cygwin parent process.

The general idea is to make sure the passwd DB contains the correct
home dir and then use that.
It's a long Unix tradition that you can set HOME to something arbitrary before starting a shell (and if you choose a relative or non-existing path, it's your own fault). This should be maintained, whether doing so within Cygwin or from Windows. As you say, if somebody's setting HOME in Windows, they are doing this on purpose. And people shouldn't be told to set HOME to a value not valid in the environment they are setting it. Also considering that two applications were mentioned that use it within Windows. Finally, I think people shouldn't be told they cannot use the traditional Unix feature (well-known to some) anymore because they should use some more modern DB configuration method (system-specific, to be studied...).


Problem reports:
Unsubscribe info:

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