cygwin-3.1.0 and mintty from desktop shortcut

[Takashi Yano]

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 <cygwin@cygwin.com> 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 <takashi.yano@nifty.ne.jp>