[ANNOUNCEMENT] cygwin 3.1.0-1

classic Classic list List threaded Threaded
38 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: cygwin-3.1.0 and mintty from desktop shortcut

Achim Gratz
Rainer Emrich writes:
> I really don't know if this the same issue. But I had similiar symptom
> after upgrade from 3.0.7 to 3.1.4 on Windows 7. The mintty window pops
> up, but I got no command prompt. The bash shell used all of one CPU for
> ever. I tried several things. The solution after hours was uninstalling
> the gettext package. That's reproducable. After installing the gettext
> package I get the hang. After uninstalling all's back to normal. That's
> strange.

I don't really want to imagine how you came up with that observation,
but yes, that's the same problem I am facing.  This is my current
workaround now:

1. Rename /usr/share/locale to something else, like local.bak.
2. Start mintty in the usual way.
3. Rename the directory from step 1 back to /usr/share/local.
4. Work just like the problem never existed either in the shell running
inside the mintty or even start a new mintty.


Andrew, can we have a Goldstar for Rainer, please?


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

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves
--
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
Reply | Threaded
Open this post in threaded view
|

Re: cygwin-3.1.0 and mintty from desktop shortcut

Achim Gratz
In reply to this post by Cygwin list mailing list
Takashi Yano via Cygwin writes:
> Achim, can you build mintty locally? If so, could you please
> apply attahed patch to mintty 3.1.4 and report the output
> in mintty window?

I guess I can, but it will take time I don't have right now.  I'll see
what I can wedge in next week.

What I did figure out today is this:

The last working snapshot is the 2019-08-19 one, the next one
(2019-11-03) starts to fail already.  Unfortunately, between these two
snapshots most of the changes were put in.

Same as with your mintty
request I'll try to bisect the actual com,mit responsible, but I first
need to set up a build environment on another machione (SSD on my work
laptop is too full).  Again, unlikely to happen this or next week.


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

SD adaptation for Waldorf Blofeld V1.15B11:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
--
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
Reply | Threaded
Open this post in threaded view
|

Re: cygwin-3.1.0 and mintty from desktop shortcut

Thomas Wolff
In reply to this post by Achim Gratz

Am 12.03.2020 um 20:39 schrieb Achim Gratz:

> Rainer Emrich writes:
>> I really don't know if this the same issue. But I had similiar symptom
>> after upgrade from 3.0.7 to 3.1.4 on Windows 7. The mintty window pops
>> up, but I got no command prompt. The bash shell used all of one CPU for
>> ever. I tried several things. The solution after hours was uninstalling
>> the gettext package. That's reproducable. After installing the gettext
>> package I get the hang. After uninstalling all's back to normal. That's
>> strange.
> I don't really want to imagine how you came up with that observation,
> but yes, that's the same problem I am facing.  This is my current
> workaround now:
>
> 1. Rename /usr/share/locale to something else, like local.bak.
> 2. Start mintty in the usual way.
> 3. Rename the directory from step 1 back to /usr/share/local.
> 4. Work just like the problem never existed either in the shell running
> inside the mintty or even start a new mintty.
>
>
> Andrew, can we have a Goldstar for Rainer, please?
This does not yet explain the issue, or did I miss a point? Since only
few people seem to have a problem, what's the locale you run in? Any
other special configuration?
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
Reply | Threaded
Open this post in threaded view
|

Re: cygwin-3.1.0 and mintty from desktop shortcut

Cygwin list mailing list
In reply to this post by Achim Gratz
On Thu, 12 Mar 2020 20:39:39 +0100
Achim Gratz wrote:
> I don't really want to imagine how you came up with that observation,
> but yes, that's the same problem I am facing.  This is my current
> workaround now:
>
> 1. Rename /usr/share/locale to something else, like local.bak.
> 2. Start mintty in the usual way.
> 3. Rename the directory from step 1 back to /usr/share/local.
> 4. Work just like the problem never existed either in the shell running
> inside the mintty or even start a new mintty.

I guess renaming /usr/share/locale/locale.alias is enough.

--
Takashi Yano <[hidden email]>
--
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
Reply | Threaded
Open this post in threaded view
|

Re: cygwin-3.1.0 and mintty from desktop shortcut

Cygwin list mailing list
On Fri, 13 Mar 2020 10:03:25 +0900
Takashi Yano wrote:

> On Thu, 12 Mar 2020 20:39:39 +0100
> Achim Gratz wrote:
> > I don't really want to imagine how you came up with that observation,
> > but yes, that's the same problem I am facing.  This is my current
> > workaround now:
> >
> > 1. Rename /usr/share/locale to something else, like local.bak.
> > 2. Start mintty in the usual way.
> > 3. Rename the directory from step 1 back to /usr/share/local.
> > 4. Work just like the problem never existed either in the shell running
> > inside the mintty or even start a new mintty.
>
> I guess renaming /usr/share/locale/locale.alias is enough.

Could you please test if the following cygwin1.dll resolve
the problem?

http://tyan0.dip.jp/cygwin/x86/test/cygwin1-20200313.dll.xz
http://tyan0.dip.jp/cygwin/x86_64/test/cygwin1-20200313.dll.xz

--
Takashi Yano <[hidden email]>
--
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
Reply | Threaded
Open this post in threaded view
|

Re: cygwin-3.1.0 and mintty from desktop shortcut

Rainer Emrich-2
Am 13.03.2020 um 03:01 schrieb Takashi Yano via Cygwin:

> On Fri, 13 Mar 2020 10:03:25 +0900
> Takashi Yano wrote:
>> On Thu, 12 Mar 2020 20:39:39 +0100
>> Achim Gratz wrote:
>>> I don't really want to imagine how you came up with that observation,
>>> but yes, that's the same problem I am facing.  This is my current
>>> workaround now:
>>>
>>> 1. Rename /usr/share/locale to something else, like local.bak.
>>> 2. Start mintty in the usual way.
>>> 3. Rename the directory from step 1 back to /usr/share/local.
>>> 4. Work just like the problem never existed either in the shell running
>>> inside the mintty or even start a new mintty.
>>
>> I guess renaming /usr/share/locale/locale.alias is enough.
>
> Could you please test if the following cygwin1.dll resolve
> the problem?
>
> http://tyan0.dip.jp/cygwin/x86/test/cygwin1-20200313.dll.xz
> http://tyan0.dip.jp/cygwin/x86_64/test/cygwin1-20200313.dll.xz
>
This one solves the issue. Tanks for alll your work!

Rainer


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

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: cygwin-3.1.0 and mintty from desktop shortcut

Achim Gratz
In reply to this post by Cygwin list mailing list
Takashi Yano via Cygwin writes:
>> I guess renaming /usr/share/locale/locale.alias is enough.

Yes it does.

> Could you please test if the following cygwin1.dll resolve
> the problem?

Mintty doesn't start when I just replace this DLL, I get a Windows error
"0x00000022".  That usually means I should have replaced some other part
of Cygwin together with the DLL or I messed the replacement up somehow.
I can try again later or whichever snapshot gets that change.


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

Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables
--
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
Reply | Threaded
Open this post in threaded view
|

Re: cygwin-3.1.0 and mintty from desktop shortcut

Cygwin list mailing list
On 3/13/2020 5:26 PM, Achim Gratz wrote:

> Takashi Yano via Cygwin writes:
>>> I guess renaming /usr/share/locale/locale.alias is enough.
>
> Yes it does.
>
>> Could you please test if the following cygwin1.dll resolve
>> the problem?
>
> Mintty doesn't start when I just replace this DLL, I get a Windows error
> "0x00000022".  That usually means I should have replaced some other part
> of Cygwin together with the DLL or I messed the replacement up somehow.
> I can try again later or whichever snapshot gets that change.

It's possible that you also need to copy /usr/bin/cygwin-console-helper.exe from
a recent Cygwin release.

Ken
--
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
Reply | Threaded
Open this post in threaded view
|

Re: cygwin-3.1.0 and mintty from desktop shortcut

Achim Gratz
Ken Brown via Cygwin writes:
> It's possible that you also need to copy
> /usr/bin/cygwin-console-helper.exe from a recent Cygwin release.

I was stgarting from a 3.1.4 install (and the latest snapshot from
cygwin.com works on the same installation).  I'll look at it again
later.


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

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves
--
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
Reply | Threaded
Open this post in threaded view
|

Re: cygwin-3.1.0 and mintty from desktop shortcut

Achim Gratz
In reply to this post by Cygwin list mailing list
Takashi Yano via Cygwin writes:
>> 1. Rename /usr/share/locale to something else, like local.bak.
>> 2. Start mintty in the usual way.
>> 3. Rename the directory from step 1 back to /usr/share/local.
>> 4. Work just like the problem never existed either in the shell running
>> inside the mintty or even start a new mintty.
>
> I guess renaming /usr/share/locale/locale.alias is enough.

I've had some time to look into this problem again after having updated
Cygwin to the latest and greatest.  Indeed, when

/usr/share/locale/locale.alias

gets renamed, the problem also goes away.  This is great because I don't
really need the locale aliases for anything.  Btw, my laptop got
upgraded to Win10 1909 (Enterprise) in the meantime, so the issue isn't
specific to 1803 as was supected earlier.

I then tried to figure out what exactly causes the problem and it turns
out that it's the _presence_ of this file with the additional condition
that it must not be owned by the user starting the mintty/shell.  Since
I install Cygwin on my work laptop with a different (admin) account and
not my (non-admin) user account, that explains why I am seeing the
problem there and not on other machines.  Before you are going to
suggest that it's the admin vs. non-admin rights: no, if I create a
locale.alias with my user account (either as an empty file or a copy of
the backup file), then the admin account is unable to start a shell in
mintty successfully.  I have no idea why the ownership of a file that
onnly should get read (and is readable by everyone) would have the
effect I'm seeing, but maybe that gives the clue on where to look for a
fix.


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

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs
--
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple
Reply | Threaded
Open this post in threaded view
|

Re: cygwin-3.1.0 and mintty from desktop shortcut

Cygwin list mailing list
On Sat, 06 Jun 2020 13:20:16 +0200
ASSI wrote:

> Takashi Yano via Cygwin writes:
> >> 1. Rename /usr/share/locale to something else, like local.bak.
> >> 2. Start mintty in the usual way.
> >> 3. Rename the directory from step 1 back to /usr/share/local.
> >> 4. Work just like the problem never existed either in the shell running
> >> inside the mintty or even start a new mintty.
> >
> > I guess renaming /usr/share/locale/locale.alias is enough.
>
> I've had some time to look into this problem again after having updated
> Cygwin to the latest and greatest.  Indeed, when
>
> /usr/share/locale/locale.alias
>
> gets renamed, the problem also goes away.  This is great because I don't
> really need the locale aliases for anything.  Btw, my laptop got
> upgraded to Win10 1909 (Enterprise) in the meantime, so the issue isn't
> specific to 1803 as was supected earlier.
>
> I then tried to figure out what exactly causes the problem and it turns
> out that it's the _presence_ of this file with the additional condition
> that it must not be owned by the user starting the mintty/shell.  Since
> I install Cygwin on my work laptop with a different (admin) account and
> not my (non-admin) user account, that explains why I am seeing the
> problem there and not on other machines.  Before you are going to
> suggest that it's the admin vs. non-admin rights: no, if I create a
> locale.alias with my user account (either as an empty file or a copy of
> the backup file), then the admin account is unable to start a shell in
> mintty successfully.  I have no idea why the ownership of a file that
> onnly should get read (and is readable by everyone) would have the
> effect I'm seeing, but maybe that gives the clue on where to look for a
> fix.

Thanks for the additional information. I tested the following steps
to confirm if the problem can be reproduced.

1. Enable Administrator account.
2. Remove all groups from account yano other than Users.
3. Install cygwin for all with gettext package as Administrator.
4. Run mintty from desktop shortcut as Administrator.
5. Run mintty from desktop shortcut as yano.

Both 4 and 5 successfully open mintty window with shell.

I wonder what is the difference between my environment and yours.

--
Takashi Yano <[hidden email]>
--
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple
Reply | Threaded
Open this post in threaded view
|

Re: cygwin-3.1.0 and mintty from desktop shortcut

Achim Gratz
Takashi Yano via Cygwin writes:
[…]
> Both 4 and 5 successfully open mintty window with shell.

…as they do for me on other machines that have different configuration.

> I wonder what is the difference between my environment and yours.

That way lies madness… and I can't really tell you as this machine is
not under my control, so tons of GP directives.  Both my user and admin
account are actually domain accounts, not local ones, and the admin
account is from a different (but federated) domain.  Again, I have no
idea if that's needed for the problem to occur, but it isn't on at least
one other machine (that is a different install type, so gets different
GP applied).  Both accounts (but especially my user account) will return
lots of data when you ask the AD for just about anything other than just
the username, so these queries take some time.

From the different workarounds that were applicable to different
versions of Cygwin and the fact it sometimes works when trying to
strace, it still seems to me that it livelocks on some unexpected
condition.


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

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
--
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple
Reply | Threaded
Open this post in threaded view
|

Re: cygwin-3.1.0 and mintty from desktop shortcut

Brian Inglis
In reply to this post by Cygwin list mailing list
On 2020-06-06 19:35, Takashi Yano via Cygwin wrote:

> On Sat, 06 Jun 2020 13:20:16 +0200
> ASSI wrote:
>> Takashi Yano via Cygwin writes:
>>>> 1. Rename /usr/share/locale to something else, like local.bak.
>>>> 2. Start mintty in the usual way.
>>>> 3. Rename the directory from step 1 back to /usr/share/local.
>>>> 4. Work just like the problem never existed either in the shell running
>>>> inside the mintty or even start a new mintty.
>>>
>>> I guess renaming /usr/share/locale/locale.alias is enough.
>>
>> I've had some time to look into this problem again after having updated
>> Cygwin to the latest and greatest.  Indeed, when
>>
>> /usr/share/locale/locale.alias
>>
>> gets renamed, the problem also goes away.  This is great because I don't
>> really need the locale aliases for anything.  Btw, my laptop got
>> upgraded to Win10 1909 (Enterprise) in the meantime, so the issue isn't
>> specific to 1803 as was supected earlier.
>>
>> I then tried to figure out what exactly causes the problem and it turns
>> out that it's the _presence_ of this file with the additional condition
>> that it must not be owned by the user starting the mintty/shell.  Since
>> I install Cygwin on my work laptop with a different (admin) account and
>> not my (non-admin) user account, that explains why I am seeing the
>> problem there and not on other machines.  Before you are going to
>> suggest that it's the admin vs. non-admin rights: no, if I create a
>> locale.alias with my user account (either as an empty file or a copy of
>> the backup file), then the admin account is unable to start a shell in
>> mintty successfully.  I have no idea why the ownership of a file that
>> onnly should get read (and is readable by everyone) would have the
>> effect I'm seeing, but maybe that gives the clue on where to look for a
>> fix.
>
> Thanks for the additional information. I tested the following steps
> to confirm if the problem can be reproduced.
>
> 1. Enable Administrator account.
> 2. Remove all groups from account yano other than Users.
> 3. Install cygwin for all with gettext package as Administrator.
> 4. Run mintty from desktop shortcut as Administrator.
> 5. Run mintty from desktop shortcut as yano.
>
> Both 4 and 5 successfully open mintty window with shell.
>
> I wonder what is the difference between my environment and yours.

Locale setting?

fhandler_tty.cc(fhandler_pty_slave::setup_locale)@2854 calls
get_langinfo@2768 calls@2781
nlsfuncs.cc(__set_locale_from_locale_alias)@1462
which opens /usr/share/locale/locale.alias@1472.

One problem I see with that is that __set_locale_from_locale_alias is meant to
be called when loadlocale fails with an unrecognized locale, but in
get_langinfo@2778 if the locale is not found, it is defaulted to C before
__set_locale_from_locale_alias is called, defeating the purpose:

  const char *locale = __loadlocale (&loc, LC_CTYPE, new_locale);
  if (!locale)
    locale = "C";

  char tmp_locale[ENCODING_LEN + 1];
  char *ret = __set_locale_from_locale_alias (locale, tmp_locale);
  if (ret)
    locale = tmp_locale;

--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in IEC units and prefixes, physical quantities in SI.]
--
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple
Reply | Threaded
Open this post in threaded view
|

Re: cygwin-3.1.0 and mintty from desktop shortcut

Cygwin list mailing list
On Sun, 7 Jun 2020 00:15:59 -0600
Brian Inglis wrote:

> On 2020-06-06 19:35, Takashi Yano via Cygwin wrote:
> > On Sat, 06 Jun 2020 13:20:16 +0200
> > ASSI wrote:
> >> Takashi Yano via Cygwin writes:
> >>>> 1. Rename /usr/share/locale to something else, like local.bak.
> >>>> 2. Start mintty in the usual way.
> >>>> 3. Rename the directory from step 1 back to /usr/share/local.
> >>>> 4. Work just like the problem never existed either in the shell running
> >>>> inside the mintty or even start a new mintty.
> >>>
> >>> I guess renaming /usr/share/locale/locale.alias is enough.
> >>
> >> I've had some time to look into this problem again after having updated
> >> Cygwin to the latest and greatest.  Indeed, when
> >>
> >> /usr/share/locale/locale.alias
> >>
> >> gets renamed, the problem also goes away.  This is great because I don't
> >> really need the locale aliases for anything.  Btw, my laptop got
> >> upgraded to Win10 1909 (Enterprise) in the meantime, so the issue isn't
> >> specific to 1803 as was supected earlier.
> >>
> >> I then tried to figure out what exactly causes the problem and it turns
> >> out that it's the _presence_ of this file with the additional condition
> >> that it must not be owned by the user starting the mintty/shell.  Since
> >> I install Cygwin on my work laptop with a different (admin) account and
> >> not my (non-admin) user account, that explains why I am seeing the
> >> problem there and not on other machines.  Before you are going to
> >> suggest that it's the admin vs. non-admin rights: no, if I create a
> >> locale.alias with my user account (either as an empty file or a copy of
> >> the backup file), then the admin account is unable to start a shell in
> >> mintty successfully.  I have no idea why the ownership of a file that
> >> onnly should get read (and is readable by everyone) would have the
> >> effect I'm seeing, but maybe that gives the clue on where to look for a
> >> fix.
> >
> > Thanks for the additional information. I tested the following steps
> > to confirm if the problem can be reproduced.
> >
> > 1. Enable Administrator account.
> > 2. Remove all groups from account yano other than Users.
> > 3. Install cygwin for all with gettext package as Administrator.
> > 4. Run mintty from desktop shortcut as Administrator.
> > 5. Run mintty from desktop shortcut as yano.
> >
> > Both 4 and 5 successfully open mintty window with shell.
> >
> > I wonder what is the difference between my environment and yours.
>
> Locale setting?
>
> fhandler_tty.cc(fhandler_pty_slave::setup_locale)@2854 calls
> get_langinfo@2768 calls@2781
> nlsfuncs.cc(__set_locale_from_locale_alias)@1462
> which opens /usr/share/locale/locale.alias@1472.
>
> One problem I see with that is that __set_locale_from_locale_alias is meant to
> be called when loadlocale fails with an unrecognized locale, but in
> get_langinfo@2778 if the locale is not found, it is defaulted to C before
> __set_locale_from_locale_alias is called, defeating the purpose:
>
>   const char *locale = __loadlocale (&loc, LC_CTYPE, new_locale);
>   if (!locale)
>     locale = "C";
>
>   char tmp_locale[ENCODING_LEN + 1];
>   char *ret = __set_locale_from_locale_alias (locale, tmp_locale);
>   if (ret)
>     locale = tmp_locale;

Hmm..., you are right. Furthermore, __set_locale_from_locale_alias()
here is completely unnecessary since it is already processed in
__loadlocale().

I will remove that code.

--
Takashi Yano <[hidden email]>
--
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple
Reply | Threaded
Open this post in threaded view
|

Re: cygwin-3.1.0 and mintty from desktop shortcut

Cygwin list mailing list
On Sun, 7 Jun 2020 16:42:52 +0900
Takashi Yano via Cygwin <[hidden email]> wrote:

> On Sun, 7 Jun 2020 00:15:59 -0600
> Brian Inglis wrote:
> > On 2020-06-06 19:35, Takashi Yano via Cygwin wrote:
> > > On Sat, 06 Jun 2020 13:20:16 +0200
> > > ASSI wrote:
> > >> Takashi Yano via Cygwin writes:
> > >>>> 1. Rename /usr/share/locale to something else, like local.bak.
> > >>>> 2. Start mintty in the usual way.
> > >>>> 3. Rename the directory from step 1 back to /usr/share/local.
> > >>>> 4. Work just like the problem never existed either in the shell running
> > >>>> inside the mintty or even start a new mintty.
> > >>>
> > >>> I guess renaming /usr/share/locale/locale.alias is enough.
> > >>
> > >> I've had some time to look into this problem again after having updated
> > >> Cygwin to the latest and greatest.  Indeed, when
> > >>
> > >> /usr/share/locale/locale.alias
> > >>
> > >> gets renamed, the problem also goes away.  This is great because I don't
> > >> really need the locale aliases for anything.  Btw, my laptop got
> > >> upgraded to Win10 1909 (Enterprise) in the meantime, so the issue isn't
> > >> specific to 1803 as was supected earlier.
> > >>
> > >> I then tried to figure out what exactly causes the problem and it turns
> > >> out that it's the _presence_ of this file with the additional condition
> > >> that it must not be owned by the user starting the mintty/shell.  Since
> > >> I install Cygwin on my work laptop with a different (admin) account and
> > >> not my (non-admin) user account, that explains why I am seeing the
> > >> problem there and not on other machines.  Before you are going to
> > >> suggest that it's the admin vs. non-admin rights: no, if I create a
> > >> locale.alias with my user account (either as an empty file or a copy of
> > >> the backup file), then the admin account is unable to start a shell in
> > >> mintty successfully.  I have no idea why the ownership of a file that
> > >> onnly should get read (and is readable by everyone) would have the
> > >> effect I'm seeing, but maybe that gives the clue on where to look for a
> > >> fix.
> > >
> > > Thanks for the additional information. I tested the following steps
> > > to confirm if the problem can be reproduced.
> > >
> > > 1. Enable Administrator account.
> > > 2. Remove all groups from account yano other than Users.
> > > 3. Install cygwin for all with gettext package as Administrator.
> > > 4. Run mintty from desktop shortcut as Administrator.
> > > 5. Run mintty from desktop shortcut as yano.
> > >
> > > Both 4 and 5 successfully open mintty window with shell.
> > >
> > > I wonder what is the difference between my environment and yours.
> >
> > Locale setting?
> >
> > fhandler_tty.cc(fhandler_pty_slave::setup_locale)@2854 calls
> > get_langinfo@2768 calls@2781
> > nlsfuncs.cc(__set_locale_from_locale_alias)@1462
> > which opens /usr/share/locale/locale.alias@1472.
> >
> > One problem I see with that is that __set_locale_from_locale_alias is meant to
> > be called when loadlocale fails with an unrecognized locale, but in
> > get_langinfo@2778 if the locale is not found, it is defaulted to C before
> > __set_locale_from_locale_alias is called, defeating the purpose:
> >
> >   const char *locale = __loadlocale (&loc, LC_CTYPE, new_locale);
> >   if (!locale)
> >     locale = "C";
> >
> >   char tmp_locale[ENCODING_LEN + 1];
> >   char *ret = __set_locale_from_locale_alias (locale, tmp_locale);
> >   if (ret)
> >     locale = tmp_locale;
>
> Hmm..., you are right. Furthermore, __set_locale_from_locale_alias()
> here is completely unnecessary since it is already processed in
> __loadlocale().

No. I was wrong. If locale alias is used, __loadlocale() returns
aliased locale. Calling __set_locale_from_locale_alias() is
necessary to resolve alias. For example, if locale is set to
"japanese", which is defined in /usr/share/locale/locale.alias,
__loadlocale() returns "japanese", while
__set_locale_from_locale_alias() returns "ja_JP.eucJP".

__loadlocale() returns NULL when the alias resolution also fails.
So the current code is as designed.

--
Takashi Yano <[hidden email]>
--
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple
Reply | Threaded
Open this post in threaded view
|

Re: cygwin-3.1.0 and mintty from desktop shortcut

Brian Inglis
On 2020-06-07 03:23, Takashi Yano via Cygwin wrote:

> On Sun, 7 Jun 2020 16:42:52 +0900
> Takashi Yano via Cygwin <[hidden email]> wrote:
>> On Sun, 7 Jun 2020 00:15:59 -0600
>> Brian Inglis wrote:
>>> On 2020-06-06 19:35, Takashi Yano via Cygwin wrote:
>>>> On Sat, 06 Jun 2020 13:20:16 +0200
>>>> ASSI wrote:
>>>>> Takashi Yano via Cygwin writes:
>>>>>>> 1. Rename /usr/share/locale to something else, like local.bak.
>>>>>>> 2. Start mintty in the usual way.
>>>>>>> 3. Rename the directory from step 1 back to /usr/share/local.
>>>>>>> 4. Work just like the problem never existed either in the shell running
>>>>>>> inside the mintty or even start a new mintty.
>>>>>>
>>>>>> I guess renaming /usr/share/locale/locale.alias is enough.
>>>>>
>>>>> I've had some time to look into this problem again after having updated
>>>>> Cygwin to the latest and greatest.  Indeed, when
>>>>>
>>>>> /usr/share/locale/locale.alias
>>>>>
>>>>> gets renamed, the problem also goes away.  This is great because I don't
>>>>> really need the locale aliases for anything.  Btw, my laptop got
>>>>> upgraded to Win10 1909 (Enterprise) in the meantime, so the issue isn't
>>>>> specific to 1803 as was supected earlier.
>>>>>
>>>>> I then tried to figure out what exactly causes the problem and it turns
>>>>> out that it's the _presence_ of this file with the additional condition
>>>>> that it must not be owned by the user starting the mintty/shell.  Since
>>>>> I install Cygwin on my work laptop with a different (admin) account and
>>>>> not my (non-admin) user account, that explains why I am seeing the
>>>>> problem there and not on other machines.  Before you are going to
>>>>> suggest that it's the admin vs. non-admin rights: no, if I create a
>>>>> locale.alias with my user account (either as an empty file or a copy of
>>>>> the backup file), then the admin account is unable to start a shell in
>>>>> mintty successfully.  I have no idea why the ownership of a file that
>>>>> onnly should get read (and is readable by everyone) would have the
>>>>> effect I'm seeing, but maybe that gives the clue on where to look for a
>>>>> fix.
>>>>
>>>> Thanks for the additional information. I tested the following steps
>>>> to confirm if the problem can be reproduced.
>>>>
>>>> 1. Enable Administrator account.
>>>> 2. Remove all groups from account yano other than Users.
>>>> 3. Install cygwin for all with gettext package as Administrator.
>>>> 4. Run mintty from desktop shortcut as Administrator.
>>>> 5. Run mintty from desktop shortcut as yano.
>>>>
>>>> Both 4 and 5 successfully open mintty window with shell.
>>>>
>>>> I wonder what is the difference between my environment and yours.
>>>
>>> Locale setting?
>>>
>>> fhandler_tty.cc(fhandler_pty_slave::setup_locale)@2854 calls
>>> get_langinfo@2768 calls@2781
>>> nlsfuncs.cc(__set_locale_from_locale_alias)@1462
>>> which opens /usr/share/locale/locale.alias@1472.
>>>
>>> One problem I see with that is that __set_locale_from_locale_alias is meant to
>>> be called when loadlocale fails with an unrecognized locale, but in
>>> get_langinfo@2778 if the locale is not found, it is defaulted to C before
>>> __set_locale_from_locale_alias is called, defeating the purpose:
>>>
>>>   const char *locale = __loadlocale (&loc, LC_CTYPE, new_locale);
>>>   if (!locale)
>>>     locale = "C";
>>>
>>>   char tmp_locale[ENCODING_LEN + 1];
>>>   char *ret = __set_locale_from_locale_alias (locale, tmp_locale);
>>>   if (ret)
>>>     locale = tmp_locale;
>>
>> Hmm..., you are right. Furthermore, __set_locale_from_locale_alias()
>> here is completely unnecessary since it is already processed in
>> __loadlocale().
>
> No. I was wrong. If locale alias is used, __loadlocale() returns
> aliased locale. Calling __set_locale_from_locale_alias() is
> necessary to resolve alias. For example, if locale is set to
> "japanese", which is defined in /usr/share/locale/locale.alias,
> __loadlocale() returns "japanese", while
> __set_locale_from_locale_alias() returns "ja_JP.eucJP".
>
> __loadlocale() returns NULL when the alias resolution also fails.
> So the current code is as designed.

But if __loadlocale() returns a non-NULL string, then the locale and/or alias
has been resolved and loaded, so it is unnecessary to further call
__set_locale_from_locale_alias().
If __loadlocale() returns a NULL string, then you need to set it to the global
default locale "C.ASCII".

--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in IEC units and prefixes, physical quantities in SI.]
--
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple
Reply | Threaded
Open this post in threaded view
|

Re: cygwin-3.1.0 and mintty from desktop shortcut

Cygwin list mailing list
On Sun, 7 Jun 2020 21:20:09 -0600
Brian Inglis wrote:

> On 2020-06-07 03:23, Takashi Yano via Cygwin wrote:
> > On Sun, 7 Jun 2020 16:42:52 +0900
> > Takashi Yano via Cygwin <[hidden email]> wrote:
> >> On Sun, 7 Jun 2020 00:15:59 -0600
> >> Brian Inglis wrote:
> >>> On 2020-06-06 19:35, Takashi Yano via Cygwin wrote:
> >>>> On Sat, 06 Jun 2020 13:20:16 +0200
> >>>> ASSI wrote:
> >>>>> Takashi Yano via Cygwin writes:
> >>>>>>> 1. Rename /usr/share/locale to something else, like local.bak.
> >>>>>>> 2. Start mintty in the usual way.
> >>>>>>> 3. Rename the directory from step 1 back to /usr/share/local.
> >>>>>>> 4. Work just like the problem never existed either in the shell running
> >>>>>>> inside the mintty or even start a new mintty.
> >>>>>>
> >>>>>> I guess renaming /usr/share/locale/locale.alias is enough.
> >>>>>
> >>>>> I've had some time to look into this problem again after having updated
> >>>>> Cygwin to the latest and greatest.  Indeed, when
> >>>>>
> >>>>> /usr/share/locale/locale.alias
> >>>>>
> >>>>> gets renamed, the problem also goes away.  This is great because I don't
> >>>>> really need the locale aliases for anything.  Btw, my laptop got
> >>>>> upgraded to Win10 1909 (Enterprise) in the meantime, so the issue isn't
> >>>>> specific to 1803 as was supected earlier.
> >>>>>
> >>>>> I then tried to figure out what exactly causes the problem and it turns
> >>>>> out that it's the _presence_ of this file with the additional condition
> >>>>> that it must not be owned by the user starting the mintty/shell.  Since
> >>>>> I install Cygwin on my work laptop with a different (admin) account and
> >>>>> not my (non-admin) user account, that explains why I am seeing the
> >>>>> problem there and not on other machines.  Before you are going to
> >>>>> suggest that it's the admin vs. non-admin rights: no, if I create a
> >>>>> locale.alias with my user account (either as an empty file or a copy of
> >>>>> the backup file), then the admin account is unable to start a shell in
> >>>>> mintty successfully.  I have no idea why the ownership of a file that
> >>>>> onnly should get read (and is readable by everyone) would have the
> >>>>> effect I'm seeing, but maybe that gives the clue on where to look for a
> >>>>> fix.
> >>>>
> >>>> Thanks for the additional information. I tested the following steps
> >>>> to confirm if the problem can be reproduced.
> >>>>
> >>>> 1. Enable Administrator account.
> >>>> 2. Remove all groups from account yano other than Users.
> >>>> 3. Install cygwin for all with gettext package as Administrator.
> >>>> 4. Run mintty from desktop shortcut as Administrator.
> >>>> 5. Run mintty from desktop shortcut as yano.
> >>>>
> >>>> Both 4 and 5 successfully open mintty window with shell.
> >>>>
> >>>> I wonder what is the difference between my environment and yours.
> >>>
> >>> Locale setting?
> >>>
> >>> fhandler_tty.cc(fhandler_pty_slave::setup_locale)@2854 calls
> >>> get_langinfo@2768 calls@2781
> >>> nlsfuncs.cc(__set_locale_from_locale_alias)@1462
> >>> which opens /usr/share/locale/locale.alias@1472.
> >>>
> >>> One problem I see with that is that __set_locale_from_locale_alias is meant to
> >>> be called when loadlocale fails with an unrecognized locale, but in
> >>> get_langinfo@2778 if the locale is not found, it is defaulted to C before
> >>> __set_locale_from_locale_alias is called, defeating the purpose:
> >>>
> >>>   const char *locale = __loadlocale (&loc, LC_CTYPE, new_locale);
> >>>   if (!locale)
> >>>     locale = "C";
> >>>
> >>>   char tmp_locale[ENCODING_LEN + 1];
> >>>   char *ret = __set_locale_from_locale_alias (locale, tmp_locale);
> >>>   if (ret)
> >>>     locale = tmp_locale;
> >>
> >> Hmm..., you are right. Furthermore, __set_locale_from_locale_alias()
> >> here is completely unnecessary since it is already processed in
> >> __loadlocale().
> >
> > No. I was wrong. If locale alias is used, __loadlocale() returns
> > aliased locale. Calling __set_locale_from_locale_alias() is
> > necessary to resolve alias. For example, if locale is set to
> > "japanese", which is defined in /usr/share/locale/locale.alias,
> > __loadlocale() returns "japanese", while
> > __set_locale_from_locale_alias() returns "ja_JP.eucJP".
> >
> > __loadlocale() returns NULL when the alias resolution also fails.
> > So the current code is as designed.
>
> But if __loadlocale() returns a non-NULL string, then the locale and/or alias
> has been resolved and loaded, so it is unnecessary to further call
> __set_locale_from_locale_alias().

This is not true. When __loadlocale() returns non-NULL, the third
argument of __loadlocale() is returned.
Please see newlib/libc/locale/locale.c.

So, as for return value of __loadlocale(), alias is not resolved.
Alias-resolved locale is used in __loadlocale() only internally.

> If __loadlocale() returns a NULL string, then you need to set it to the global
> default locale "C.ASCII".


--
Takashi Yano <[hidden email]>
--
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple
Reply | Threaded
Open this post in threaded view
|

Re: cygwin-3.1.0 and mintty from desktop shortcut

Brian Inglis
On 2020-06-08 04:27, Takashi Yano via Cygwin wrote:

> On Sun, 7 Jun 2020 21:20:09 -0600
> Brian Inglis wrote:
>> On 2020-06-07 03:23, Takashi Yano via Cygwin wrote:
>>> On Sun, 7 Jun 2020 16:42:52 +0900
>>> Takashi Yano via Cygwin <[hidden email]> wrote:
>>>> On Sun, 7 Jun 2020 00:15:59 -0600
>>>> Brian Inglis wrote:
>>>>> On 2020-06-06 19:35, Takashi Yano via Cygwin wrote:
>>>>>> On Sat, 06 Jun 2020 13:20:16 +0200
>>>>>> ASSI wrote:
>>>>>>> Takashi Yano via Cygwin writes:
>>>>>>>>> 1. Rename /usr/share/locale to something else, like local.bak.
>>>>>>>>> 2. Start mintty in the usual way.
>>>>>>>>> 3. Rename the directory from step 1 back to /usr/share/local.
>>>>>>>>> 4. Work just like the problem never existed either in the shell running
>>>>>>>>> inside the mintty or even start a new mintty.
>>>>>>>>
>>>>>>>> I guess renaming /usr/share/locale/locale.alias is enough.
>>>>>>>
>>>>>>> I've had some time to look into this problem again after having updated
>>>>>>> Cygwin to the latest and greatest.  Indeed, when
>>>>>>>
>>>>>>> /usr/share/locale/locale.alias
>>>>>>>
>>>>>>> gets renamed, the problem also goes away.  This is great because I don't
>>>>>>> really need the locale aliases for anything.  Btw, my laptop got
>>>>>>> upgraded to Win10 1909 (Enterprise) in the meantime, so the issue isn't
>>>>>>> specific to 1803 as was supected earlier.
>>>>>>>
>>>>>>> I then tried to figure out what exactly causes the problem and it turns
>>>>>>> out that it's the _presence_ of this file with the additional condition
>>>>>>> that it must not be owned by the user starting the mintty/shell.  Since
>>>>>>> I install Cygwin on my work laptop with a different (admin) account and
>>>>>>> not my (non-admin) user account, that explains why I am seeing the
>>>>>>> problem there and not on other machines.  Before you are going to
>>>>>>> suggest that it's the admin vs. non-admin rights: no, if I create a
>>>>>>> locale.alias with my user account (either as an empty file or a copy of
>>>>>>> the backup file), then the admin account is unable to start a shell in
>>>>>>> mintty successfully.  I have no idea why the ownership of a file that
>>>>>>> onnly should get read (and is readable by everyone) would have the
>>>>>>> effect I'm seeing, but maybe that gives the clue on where to look for a
>>>>>>> fix.
>>>>>>
>>>>>> Thanks for the additional information. I tested the following steps
>>>>>> to confirm if the problem can be reproduced.
>>>>>>
>>>>>> 1. Enable Administrator account.
>>>>>> 2. Remove all groups from account yano other than Users.
>>>>>> 3. Install cygwin for all with gettext package as Administrator.
>>>>>> 4. Run mintty from desktop shortcut as Administrator.
>>>>>> 5. Run mintty from desktop shortcut as yano.
>>>>>>
>>>>>> Both 4 and 5 successfully open mintty window with shell.
>>>>>>
>>>>>> I wonder what is the difference between my environment and yours.
>>>>>
>>>>> Locale setting?
>>>>>
>>>>> fhandler_tty.cc(fhandler_pty_slave::setup_locale)@2854 calls
>>>>> get_langinfo@2768 calls@2781
>>>>> nlsfuncs.cc(__set_locale_from_locale_alias)@1462
>>>>> which opens /usr/share/locale/locale.alias@1472.
>>>>>
>>>>> One problem I see with that is that __set_locale_from_locale_alias is meant to
>>>>> be called when loadlocale fails with an unrecognized locale, but in
>>>>> get_langinfo@2778 if the locale is not found, it is defaulted to C before
>>>>> __set_locale_from_locale_alias is called, defeating the purpose:
>>>>>
>>>>>   const char *locale = __loadlocale (&loc, LC_CTYPE, new_locale);
>>>>>   if (!locale)
>>>>>     locale = "C";
>>>>>
>>>>>   char tmp_locale[ENCODING_LEN + 1];
>>>>>   char *ret = __set_locale_from_locale_alias (locale, tmp_locale);
>>>>>   if (ret)
>>>>>     locale = tmp_locale;
>>>>
>>>> Hmm..., you are right. Furthermore, __set_locale_from_locale_alias()
>>>> here is completely unnecessary since it is already processed in
>>>> __loadlocale().
>>>
>>> No. I was wrong. If locale alias is used, __loadlocale() returns
>>> aliased locale. Calling __set_locale_from_locale_alias() is
>>> necessary to resolve alias. For example, if locale is set to
>>> "japanese", which is defined in /usr/share/locale/locale.alias,
>>> __loadlocale() returns "japanese", while
>>> __set_locale_from_locale_alias() returns "ja_JP.eucJP".
>>>
>>> __loadlocale() returns NULL when the alias resolution also fails.
>>> So the current code is as designed.
>>
>> But if __loadlocale() returns a non-NULL string, then the locale and/or alias
>> has been resolved and loaded, so it is unnecessary to further call
>> __set_locale_from_locale_alias().
>
> This is not true. When __loadlocale() returns non-NULL, the third
> argument of __loadlocale() is returned.
> Please see newlib/libc/locale/locale.c.
>
> So, as for return value of __loadlocale(), alias is not resolved.
> Alias-resolved locale is used in __loadlocale() only internally.

The alias value is returned, so that the library can avoid re-resolving it and
re-loading locale categories if the same value is passed again: they do not
assume that any returned value will be saved and reused by the most callers in
subsequent uses, so avoid having to re-resolve aliases by keeping them around.

Internally to __loadlocale(), the alias is resolved and the resolved value is
used to set the base locale information and load all the associated locale
categories: I have custom locale/regional settings in Linux and Windows, so I
know these work well.

[It would be clearer if the charset handling was refactored into a separate
function, and also doing the language and territory separately would help
declutter __loadlocale(), but who has the time and knowledge?]

--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in IEC units and prefixes, physical quantities in SI.]
--
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple
12