From: Brian Inglis <Brian.Inglis@SystematicSw.ab.ca>
To: cygwin@cygwin.com
Subject: Re: cygwin-3.1.0 and mintty from desktop shortcut
Date: Sun, 7 Jun 2020 21:20:09 -0600 [thread overview]
Message-ID: <17858277-929a-2652-b584-67dc71a7706b@SystematicSw.ab.ca> (raw)
In-Reply-To: <20200607182327.9e291a5947adad7ca418204e@nifty.ne.jp>
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().
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.]
next prev parent reply other threads:[~2020-06-08 3:20 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-16 23:26 [ANNOUNCEMENT] cygwin 3.1.0-1 Corinna Vinschen
2019-12-17 6:35 ` Thomas Wolff
2019-12-17 8:49 ` [GOLDSTAR][PLUSH HIPPO] " Corinna Vinschen
2019-12-17 20:58 ` Andrew Schulman via cygwin
2019-12-17 18:57 ` cygwin-3.1.0 and mintty from desktop shortcut (was: [ANNOUNCEMENT] cygwin 3.1.0-1) Achim Gratz
2019-12-18 9:07 ` Corinna Vinschen
2019-12-18 16:56 ` cygwin-3.1.0 and mintty from desktop shortcut Achim Gratz
2020-03-11 17:47 ` Achim Gratz
2020-03-11 19:51 ` Corinna Vinschen
2020-03-12 2:56 ` Rainer Emrich
2020-03-12 19:39 ` Achim Gratz
2020-03-12 21:36 ` Thomas Wolff
2020-03-13 1:03 ` Takashi Yano
2020-03-13 2:01 ` Takashi Yano
2020-03-13 15:09 ` Rainer Emrich
2020-03-13 21:26 ` Achim Gratz
2020-03-13 22:20 ` Ken Brown
2020-03-14 16:11 ` Achim Gratz
2020-06-06 11:20 ` ASSI
2020-06-07 1:35 ` Takashi Yano
2020-06-07 5:29 ` ASSI
2020-06-07 6:15 ` Brian Inglis
2020-06-07 7:42 ` Takashi Yano
2020-06-07 9:23 ` Takashi Yano
2020-06-08 3:20 ` Brian Inglis [this message]
2020-06-08 10:27 ` Takashi Yano
2020-06-08 19:24 ` Brian Inglis
2021-03-22 20:13 ` Achim Gratz
2020-03-12 10:57 ` Takashi Yano
2020-03-12 19:46 ` Achim Gratz
2019-12-18 12:28 ` cygwin-3.1.0 and mintty from desktop shortcut (was: [ANNOUNCEMENT] cygwin 3.1.0-1) Takashi Yano
2019-12-18 17:17 ` cygwin-3.1.0 and mintty from desktop shortcut Achim Gratz
2019-12-18 10:18 ` [ANNOUNCEMENT] cygwin 3.1.0-1 Henning
2019-12-18 11:25 ` Corinna Vinschen
2019-12-20 9:40 ` Henning
2019-12-20 10:22 ` Corinna Vinschen
2019-12-20 16:20 ` Henning
2020-01-13 21:30 ` Houder
2020-01-14 0:20 ` Ken Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=17858277-929a-2652-b584-67dc71a7706b@SystematicSw.ab.ca \
--to=brian.inglis@systematicsw.ab.ca \
--cc=cygwin@cygwin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).