[ANNOUNCEMENT] Updated: Cygwin 2.2.0-1

[ANNOUNCEMENT] Updated: Cygwin 2.2.0-1

[Corinna Vinschen]

Hi Cygwin friends and users,


I released another version of Cygwin.  The version number is 2.2.0-1.


What's new:
-----------

- New APIs: getcontext, setcontext, makecontext, swapcontext.

- New functions: sigsetjmp, siglongjmp.
  These were only available as macros up to now, but POSIX requires that
  siglongjmp has to be available as function.


What changed:
-------------

- When started from a non-Cygwin process, check if $HOME starts with a
  slash (absolute POSIX path).  Otherwise ignore it.
  Addresses: https://cygwin.com/ml/cygwin/2015-07/msg00344.html


Bug Fixes
---------

- Fix potential hang running ldd(1).
  Addresses: https://cygwin.com/ml/cygwin/2015-07/msg00292.html

- Fix crashes under AllocationPreference=0x100000 condition
  Addresses: https://cygwin.com/ml/cygwin/2015-02/msg00765.html

- x86_64 only: Implement memset, memmove, memcpy, wmemmove, wmemcpy in
  assembler derived from NetBSD.
  Addresses: https://cygwin.com/ml/cygwin-patches/2015-q3/msg00010.html


Have fun,
Corinna

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

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

Re: [ANNOUNCEMENT] Updated: Cygwin 2.2.0-1

[Thomas Wolff]

Am 03.08.2015 um 15:19 schrieb Corinna Vinschen:
> - When started from a non-Cygwin process, check if $HOME starts with a
>    slash (absolute POSIX path).  Otherwise ignore it.
>    Addresses: https://cygwin.com/ml/cygwin/2015-07/msg00344.html
I would expect $HOME to be considered if it denotes an absolute path,
even in Windows notation, and fortunately it still works :)
On the other hand, if HOME is something like set HOME=bla, a new
directory /usr/bin/bla is created and initialised as home directory.
Don't know whether that's desirable, but in fact it's not being ignored.
Thomas

---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus


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

Re: [ANNOUNCEMENT] Updated: Cygwin 2.2.0-1

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 946 bytes --]

On Aug  3 20:43, Thomas Wolff wrote:
> Am 03.08.2015 um 15:19 schrieb Corinna Vinschen:
> >- When started from a non-Cygwin process, check if $HOME starts with a
> >   slash (absolute POSIX path).  Otherwise ignore it.
> >   Addresses: https://cygwin.com/ml/cygwin/2015-07/msg00344.html
> I would expect $HOME to be considered if it denotes an absolute path,
> even in Windows notation, and fortunately it still works :)
> On the other hand, if HOME is something like set HOME=bla, a new
> directory /usr/bin/bla is created and initialised as home directory.
> Don't know whether that's desirable, but in fact it's not being ignored.
> Thomas

It's ignored as $HOME in the Cygwin DLL.  It's apparently not ignored in
the base-files package, but that's another problem.


Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [ANNOUNCEMENT] Updated: Cygwin 2.2.0-1

[Achim Gratz]

Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:
> It's ignored as $HOME in the Cygwin DLL.  It's apparently not ignored in
> the base-files package, but that's another problem.

...to which the possible solutions are:

1. Not hand a botched HOME environment variable to Cygwin processes.

2. Do the same checks as the Cygwin DLL and fall back to some more sensible
default if HOME is botched.

3. Ignore the issue.

So which one?


Regards,
Achim.


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

Re: [ANNOUNCEMENT] Updated: Cygwin 2.2.0-1

[Warren Young]

On Aug 4, 2015, at 1:50 AM, Achim Gratz <Stromeko@nexgo.de> wrote:
> 
> Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:
>> It's ignored as $HOME in the Cygwin DLL.  It's apparently not ignored in
>> the base-files package, but that's another problem.
> 
> ...to which the possible solutions are:
> 
> 1. Not hand a botched HOME environment variable to Cygwin processes.

When you speak of this in terms of processes, I think you mean that the Cygwin DLL would need to filter the environment, which sounds heavy-handed.

If you mean that /etc/profile and such will do the filtering, that could work.

> 2. Do the same checks as the Cygwin DLL and fall back to some more sensible
> default if HOME is botched.

This isn’t a second option, it’s an implementation design for option 1.

> 3. Ignore the issue.

Here’s an interesting experiment to try on your non-Cygwin POSIX boxes:

    $ HOME=/dfjkshkds bash -l
    $ echo $HOME

Guess what it prints.

Hint: It isn’t the second-to-last field in /etc/passwd. :)




Spoiler: Apparently Cygwin is already doing the standard thing.
--
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

Re: [ANNOUNCEMENT] Updated: Cygwin 2.2.0-1

[Thomas Wolff]

Am 04.08.2015 um 20:14 schrieb Warren Young:
> On Aug 4, 2015, at 1:50 AM, Achim Gratz <Stromeko@nexgo.de> wrote:
>> Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:
>>> It's ignored as $HOME in the Cygwin DLL.  It's apparently not ignored in
>>> the base-files package, but that's another problem.
>> ...to which the possible solutions are:
>>
>> ...
>> 3. Ignore the issue.
I'd also vote for that. Current behaviour is fine.
I had just stumbled about the change description, requiring a leading
slash. But apparently that's after the initial environment
transformation which would turn $HOME into a POSIX path, so that's fine.
Thomas

---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus


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

Re: [ANNOUNCEMENT] Updated: Cygwin 2.2.0-1

[Achim Gratz]

Warren Young writes:
> When you speak of this in terms of processes, I think you mean that
> the Cygwin DLL would need to filter the environment, which sounds
> heavy-handed.

Cygwin DLL already does some conversions of the Windows environment.  It
could (hypothetically) do a more thorough job and/or sanitize the
environment to make the result more POSIX conformant.

Try defining some Wnidows environment variables that have illegal POSIX
names, for instance.

> If you mean that /etc/profile and such will do the filtering, that could work.
>
>> 2. Do the same checks as the Cygwin DLL and fall back to some more sensible
>> default if HOME is botched.
>
> This isn’t a second option, it’s an implementation design for option 1.

That's the part that involves me changing base-files.

>> 3. Ignore the issue.
>
> Here’s an interesting experiment to try on your non-Cygwin POSIX boxes:
>
>     $ HOME=/dfjkshkds bash -l
>     $ echo $HOME
>
> Guess what it prints.
>
> Hint: It isn’t the second-to-last field in /etc/passwd. :)
>
>
>
>
> Spoiler: Apparently Cygwin is already doing the standard thing.

That's why I offered to ignore the issue.  That also needs nothing to be
done by me, which is an added benefit.  :-)


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra

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

Re: [ANNOUNCEMENT] Updated: Cygwin 2.2.0-1

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2078 bytes --]

On Aug  4 20:53, Achim Gratz wrote:
> Warren Young writes:
> > Here’s an interesting experiment to try on your non-Cygwin POSIX boxes:
> >
> >     $ HOME=/dfjkshkds bash -l
> >     $ echo $HOME
> >
> > Guess what it prints.
> >
> > Hint: It isn’t the second-to-last field in /etc/passwd. :)

This is correct behaviour, of course.

> > Spoiler: Apparently Cygwin is already doing the standard thing.

No, it's not.  Or, to phrase it a bit differently, it doesn't perform
thr action it was supposed to do.  My testing seemed to be a teeny bit
half-hearted...

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

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.

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?

> That's why I offered to ignore the issue.  That also needs nothing to be
> done by me, which is an added benefit.  :-)

That may be the way to go as soon as Cygwin is doing the right thing :}


Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [ANNOUNCEMENT] Updated: Cygwin 2.2.0-1

[Thomas Wolff]

Am 05.08.2015 um 09:54 schrieb Corinna Vinschen:
> On Aug  4 20:53, Achim Gratz wrote:
>> Warren Young writes:
>>> Here’s an interesting experiment to try on your non-Cygwin POSIX boxes:
>>>
>>>      $ HOME=/dfjkshkds bash -l
>>>      $ echo $HOME
>>>
>>> Guess what it prints.
>>>
>>> Hint: It isn’t the second-to-last field in /etc/passwd. :)
> This is correct behaviour, of course.
>
>>> Spoiler: Apparently Cygwin is already doing the standard thing.
> No, it's not.  Or, to phrase it a bit differently, it doesn't perform
> thr action it was supposed to do.  My testing seemed to be a teeny bit
> half-hearted...
>
> 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.
Why?
> 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.
> 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?
Yes, other Windows software ported or inspired from POSIX may also check 
for HOME just in case (e.g. my editor does...).
Also, if somebody sets HOME in Windows, it is more intuitive to use 
Windows path syntax, so this case should be handled gracefully, just 
like PATH is converted.
Thomas

---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus


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

Re: [ANNOUNCEMENT] Updated: Cygwin 2.2.0-1

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2273 bytes --]

On Aug  5 11:09, Thomas Wolff wrote:
> Am 05.08.2015 um 09:54 schrieb Corinna Vinschen:
> >On Aug  4 20:53, Achim Gratz wrote:
> >>Warren Young writes:
> >>>Here’s an interesting experiment to try on your non-Cygwin POSIX boxes:
> >>>
> >>>     $ HOME=/dfjkshkds bash -l
> >>>     $ echo $HOME
> >>>
> >>>Guess what it prints.
> >>>
> >>>Hint: It isn’t the second-to-last field in /etc/passwd. :)
> >This is correct behaviour, of course.
> >
> >>>Spoiler: Apparently Cygwin is already doing the standard thing.
> >No, it's not.  Or, to phrase it a bit differently, it doesn't perform
> >thr action it was supposed to do.  My testing seemed to be a teeny bit
> >half-hearted...
> >
> >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.
> Why?
> >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.


Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [ANNOUNCEMENT] Updated: Cygwin 2.2.0-1

[Thomas Wolff]

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?
Yes!
>>>    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...).

Thomas

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

Re: [ANNOUNCEMENT] Updated: Cygwin 2.2.0-1

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 3010 bytes --]

On Aug  6 14:03, Thomas Wolff wrote:
> 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?
> Yes!
> >>>   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.

I have some doubts. Setting HOME in Windows is a workaround to get
other, non-Cygwin POSIX-alike stuff working, and and in many cases
because people didn't read the docs and failed to understand how to
change the account DB (up to 1.7.33 .etc.passwd only) to get the desired
result.  And no, I don't read all documentation myself, so I'm sure I
fail to use some software effectively either.

Globally setting HOME in Windows for the sake of Cygwin was partially
necessary up to the early 2000s.  For *at least* 12 years, it wasn't
anymore.

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

So, editing /etc/passwd or /etc/nsswitch.conf is *that* hard?


Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [ANNOUNCEMENT] Updated: Cygwin 2.2.0-1

[cyg Simple]

On 8/7/2015 5:04 AM, Corinna Vinschen wrote:
> 
> So, editing /etc/passwd or /etc/nsswitch.conf is *that* hard?
> 

It could be difficult due to distribution of process.  As others have
stated, leave it alone.  It's worked since day 1 it should work for the
life of Cygwin.  There is no good reason to force the change.

--
cyg Simple

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

Re: [ANNOUNCEMENT] Updated: Cygwin 2.2.0-1

[Thomas Wolff]

Am 07.08.2015 um 11:04 schrieb Corinna Vinschen:
> Globally setting HOME in Windows for the sake of Cygwin was partially
> necessary up to the early 2000s. For *at least* 12 years, it wasn't
> anymore.
>> 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...).
> So, editing /etc/passwd or /etc/nsswitch.conf is *that* hard?
Maybe not. But setting HOME is certainly easier. Especially if you're
not familiar with more specific, more modern configuration stuff, and
don't like to investigate first.
Also, there have been other valid reasons against a change; trying to
summarize:

  * Setting HOME would create a common home reference for multiple
    installations of cygwin (e.g. 32/64 bit) - strong reason.
  * Maintaining Unix tradition while accepting the syntax of the host
    system.
  * Windows software that also checks for HOME.
  * Finally, do you really want a bunch of complaints "my cygwin isn't
    finding my HOME anymore" without apparent benefit?

Thomas

---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus


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

RE: [ANNOUNCEMENT] Updated: Cygwin 2.2.0-1

[Kiehl, Horst]

[-- Attachment #1: Type: text/plain, Size: 3550 bytes --]

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 #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 6029 bytes --]

Re: [ANNOUNCEMENT] Updated: Cygwin 2.2.0-1

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2832 bytes --]

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 #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [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

Re: [ANNOUNCEMENT] Updated: Cygwin 2.2.0-1

[Andrey Repin]

Greetings, Corinna Vinschen!

> 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

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

> This sounds like a terrible idea to me.

Agree.

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

For me, it wouldn't change a thing. My %HOME% is pointed to %USERPROFILE%, so
does the nsswitch.conf do the same for Cygwin.
Either way the $HOME is pulled from will point to the same place.

>> That's why I offered to ignore the issue.  That also needs nothing to be
>> done by me, which is an added benefit.  :-)

> That may be the way to go as soon as Cygwin is doing the right thing :}

:)
Do The Right Thing(tm)!


-- 
With best regards,
Andrey Repin
Wednesday, August 5, 2015 19:34:27

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

Re: [ANNOUNCEMENT] Updated: Cygwin 2.2.0-1

[Nicholas Clark]

I totally agree that setting HOME to a relative-path is probably a Bad
Idea, and can/should be undefined behavior. As for absolute paths (and
whether they should be POSIX, Windows, or either), that's a little
less cut and dry for me.

I currently use a ton of scripts of the general form:

--------
Cygwin.bat:
   @echo off

   @pushd %~dp0
   @set TOP=%CD%
   @popd

   set PATH=C:\Windows\SYSTEM32;C:\Windows

   @set HOME=%TOP%\home\%username%
   @chdir %TOP%\installation\bin

   @start mintty.exe -e %TOP%\installation\bin\bash.exe --login -i
   exit
--------

for using Cygwin in a user-level installation to my local directory.
It's not a big deal to go through these and update them if Cygwin
loses its ability to interpret Windows-style HOME paths, but there are
probably a lot of users out there who aren't on the mailing list and
wouldn't know that this change was happening until their installations
broke.

So I'm in camp 'leave it as-is', maybe with the exception of
disallowing relative paths. :)

-Nick

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

Re: [ANNOUNCEMENT] Updated: Cygwin 2.2.0-1

[Andrey Repin]

Greetings, Nicholas Clark!

> I totally agree that setting HOME to a relative-path is probably a Bad
> Idea, and can/should be undefined behavior. As for absolute paths (and
> whether they should be POSIX, Windows, or either), that's a little
> less cut and dry for me.

> I currently use a ton of scripts of the general form:

> --------
> Cygwin.bat:
>    @echo off

>    @pushd %~dp0
>    @set TOP=%CD%
>    @popd

This wraps into

SET TOP=%~dp0

(If at all necessary to wrap it like that.)

>    set PATH=C:\Windows\SYSTEM32;C:\Windows

SET PATH=%~dp0installation\usr\sbin;%~dp0installation\bin;%SystemRoot%\System32;%SystemRoot%

>    @set HOME=%TOP%\home\%username%
>    @chdir %TOP%\installation\bin

That's just plain wrong and should not be done to begin with.

>    @start mintty.exe -e %TOP%\installation\bin\bash.exe --login -i

START /B mintty.exe -

>    exit

Don't call "EXIT" unless you have no other choice.

> for using Cygwin in a user-level installation to my local directory.

Cygwin don't care, what level you are using it from, as long as the
environment is set up correctly.

> It's not a big deal to go through these and update them if Cygwin
> loses its ability to interpret Windows-style HOME paths, but there are
> probably a lot of users out there who aren't on the mailing list and
> wouldn't know that this change was happening until their installations
> broke.

> So I'm in camp 'leave it as-is', maybe with the exception of
> disallowing relative paths. :)

I don't know how to say it politely, so I would be blunt: Your setup is wrong.
There's at least two ways to do it right, but none of them is coming close to
what you have right now.
Cygwin offers ability to make all you want pretty straight without any
tantric scripts.


-- 
With best regards,
Andrey Repin
Thursday, August 6, 2015 03:07:01

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

Re: [ANNOUNCEMENT] Updated: Cygwin 2.2.0-1

[Nicholas Clark]

You're certainly right that there are nicer ways to write that script.
My point with the sample script above is that I'm currently using a
Windows-style HOME path, and it works fine.

Chances are there are a bunch of other users out there who also use a
Windows-style HOME path in messy .bat files - I just wanted to
illuminate that making Windows paths illegal is likely to break a
whole bunch of users' scripts, and really offers no benefit.



On Wed, Aug 5, 2015 at 5:14 PM, Andrey Repin <anrdaemon@yandex.ru> wrote:
> Greetings, Nicholas Clark!
>
>> I totally agree that setting HOME to a relative-path is probably a Bad
>> Idea, and can/should be undefined behavior. As for absolute paths (and
>> whether they should be POSIX, Windows, or either), that's a little
>> less cut and dry for me.
>
>> I currently use a ton of scripts of the general form:
>
>> --------
>> Cygwin.bat:
>>    @echo off
>
>>    @pushd %~dp0
>>    @set TOP=%CD%
>>    @popd
>
> This wraps into
>
> SET TOP=%~dp0
>
> (If at all necessary to wrap it like that.)
>
>>    set PATH=C:\Windows\SYSTEM32;C:\Windows
>
> SET PATH=%~dp0installation\usr\sbin;%~dp0installation\bin;%SystemRoot%\System32;%SystemRoot%
>
>>    @set HOME=%TOP%\home\%username%
>>    @chdir %TOP%\installation\bin
>
> That's just plain wrong and should not be done to begin with.
>
>>    @start mintty.exe -e %TOP%\installation\bin\bash.exe --login -i
>
> START /B mintty.exe -
>
>>    exit
>
> Don't call "EXIT" unless you have no other choice.
>
>> for using Cygwin in a user-level installation to my local directory.
>
> Cygwin don't care, what level you are using it from, as long as the
> environment is set up correctly.
>
>> It's not a big deal to go through these and update them if Cygwin
>> loses its ability to interpret Windows-style HOME paths, but there are
>> probably a lot of users out there who aren't on the mailing list and
>> wouldn't know that this change was happening until their installations
>> broke.
>
>> So I'm in camp 'leave it as-is', maybe with the exception of
>> disallowing relative paths. :)
>
> I don't know how to say it politely, so I would be blunt: Your setup is wrong.
> There's at least two ways to do it right, but none of them is coming close to
> what you have right now.
> Cygwin offers ability to make all you want pretty straight without any
> tantric scripts.
>
>
> --
> With best regards,
> Andrey Repin
> Thursday, August 6, 2015 03:07:01
>
> 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

Re: [ANNOUNCEMENT] Updated: Cygwin 2.2.0-1

[Andrey Repin]

Greetings, Nicholas Clark!

> You're certainly right that there are nicer ways to write that script.
> My point with the sample script above is that I'm currently using a
> Windows-style HOME path, and it works fine.

If it would stop working, you'll have to o and revisit your mess to pull the
cruft out of the pipes.

> Chances are there are a bunch of other users out there who also use a
> Windows-style HOME path in messy .bat files - I just wanted to
> illuminate that making Windows paths illegal is likely to break a
> whole bunch of users' scripts, and really offers no benefit.

Chances are, they can go and revisit their mess once in a lifetime.
When 1.7.35 came out, I went and dug up every corner of my system to make sure
I no longer have the need for wrappers like yours.

Recently I started to write portable scripts for my private project and I've
replaced Cygwin's /bin/sh (which is in fact bash) with a symlink to /bin/dash.
We'll see how far I can go with it. Already found a number of scripts that
break under strict POSIX shell. None of them Cygwin scripts. Yet.


-- 
With best regards,
Andrey Repin
Thursday, August 6, 2015 14:26:24

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

Re: [ANNOUNCEMENT] Updated: Cygwin 2.2.0-1

[cyg Simple]

On 8/5/2015 3:54 AM, Corinna Vinschen wrote:
> 
> So the idea was:
> 
>   set HOME=foo		<- ignored, set HOME from passwd DB entry

I agree.

>   set HOME=C:/foo	<- same

I strongly disagree.  In fact I set HOME in the Windows environment
expecting Cygwin to map it correctly so that I can have a common HOME
for multiple installations of Cygwin.  It also allows me to to use
%HOME% in Windows scripts.

>   set HOME=//foo/bar	<- same

I agree.

>   set HOME=/foo/bar	<- valid, taken

I slightly disagree.  It boggles Windows scripts that could make use of
the variable and would only work for scripts where the working directory
device contains /foo/bar.

--
cyg Simple

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