[ANNOUNCEMENT] Updated: Cygwin 2.2.0-1

[Andrey Repin]

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