delorie.com/archives/browse.cgi | search |
X-Recipient: | archive-cygwin AT delorie DOT com |
X-Original-To: | cygwin AT cygwin DOT com |
Delivered-To: | cygwin AT cygwin DOT com |
DMARC-Filter: | OpenDMARC Filter v1.3.2 sourceware.org 139F83851C0B |
Authentication-Results: | sourceware.org; dmarc=none (p=none dis=none) |
header.from=SystematicSw.ab.ca | |
Authentication-Results: | sourceware.org; |
spf=none smtp.mailfrom=brian DOT inglis AT systematicsw DOT ab DOT ca | |
X-Authority-Analysis: | v=2.3 cv=Os7UNx3t c=1 sm=1 tr=0 |
a=kiZT5GMN3KAWqtYcXc+/4Q==:117 a=kiZT5GMN3KAWqtYcXc+/4Q==:17 | |
a=IkcTkHD0fZMA:10 a=w_pzkKWiAAAA:8 a=WSAXFJs-w6xwSYuCOU0A:9 a=QEXdDO2ut3YA:10 | |
a=sRI3_1zDfAgwuvI8zelB:22 a=pHzHmUro8NiASowvMSCR:22 a=Ew2E2A-JSTLzCXPT_086:22 | |
From: | Brian Inglis <Brian DOT Inglis AT SystematicSw DOT ab DOT ca> |
Subject: | Re: cygwin-3.1.0 and mintty from desktop shortcut |
To: | cygwin AT cygwin DOT com |
References: | <announce DOT 20191216201131 DOT 494767-1-corinna-cygwin AT cygwin DOT com> |
<87pngmx26z DOT fsf AT Rainer DOT invalid> <20191218090415 DOT GG10310 AT calimero DOT vinschen DOT de> | |
<87a77pbn5j DOT fsf AT Rainer DOT invalid> <87blp2lr6p DOT fsf AT Rainer DOT invalid> | |
<20200311195142 DOT GH4042 AT calimero DOT vinschen DOT de> | |
<c3c4e96a-63bc-5b7d-5fb5-2ad21ec36cdf AT emrich-ebersheim DOT de> | |
<87d09htlac DOT fsf AT Rainer DOT invalid> | |
<20200313100325 DOT fe62798353f4c719ecf565e0 AT nifty DOT ne DOT jp> | |
<87v9k4e8zz DOT fsf AT Otto DOT invalid> | |
<20200607103528 DOT 2eaea7de72b0afaa43d0b335 AT nifty DOT ne DOT jp> | |
<d5f8450c-c6cd-b790-6308-85d5d772606d AT SystematicSw DOT ab DOT ca> | |
<20200607164252 DOT 600bf8b688d2f543dc12f373 AT nifty DOT ne DOT jp> | |
<20200607182327 DOT 9e291a5947adad7ca418204e AT nifty DOT ne DOT jp> | |
Autocrypt: | addr=Brian DOT Inglis AT SystematicSw DOT ab DOT ca; prefer-encrypt=mutual; |
keydata= | |
mDMEXopx8xYJKwYBBAHaRw8BAQdAnCK0qv/xwUCCZQoA9BHRYpstERrspfT0NkUWQVuoePa0 | |
LkJyaWFuIEluZ2xpcyA8QnJpYW4uSW5nbGlzQFN5c3RlbWF0aWNTdy5hYi5jYT6IlgQTFggA | |
PhYhBMM5/lbU970GBS2bZB62lxu92I8YBQJeinHzAhsDBQkJZgGABQsJCAcCBhUKCQgLAgQW | |
AgMBAh4BAheAAAoJEB62lxu92I8Y0ioBAI8xrggNxziAVmr+Xm6nnyjoujMqWcq3oEhlYGAO | |
WacZAQDFtdDx2koSVSoOmfaOyRTbIWSf9/Cjai29060fsmdsDLg4BF6KcfMSCisGAQQBl1UB | |
BQEBB0Awv8kHI2PaEgViDqzbnoe8B9KMHoBZLS92HdC7ZPh8HQMBCAeIfgQYFggAJhYhBMM5 | |
/lbU970GBS2bZB62lxu92I8YBQJeinHzAhsMBQkJZgGAAAoJEB62lxu92I8YZwUBAJw/74rF | |
IyaSsGI7ewCdCy88Lce/kdwX7zGwid+f8NZ3AQC/ezTFFi5obXnyMxZJN464nPXiggtT9gN5 | |
RSyTY8X+AQ== | |
Organization: | Systematic Software |
Message-ID: | <17858277-929a-2652-b584-67dc71a7706b@SystematicSw.ab.ca> |
Date: | Sun, 7 Jun 2020 21:20:09 -0600 |
User-Agent: | Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 |
Thunderbird/68.9.0 | |
MIME-Version: | 1.0 |
In-Reply-To: | <20200607182327.9e291a5947adad7ca418204e@nifty.ne.jp> |
X-CMAE-Envelope: | MS4wfNmWumhulLyohCNCHhe59NLIehFmvagjAdw7eh7FkfkLQXftiGK3wTX0KNdub9kSjdCGrjWbzhsZOsZ6bH9wB6OCSoQZhMhhLK14ploRBgaQaMx+BrV8 |
dfyKUw++cwpGKf0+8qYGY6C2E0TrzaOpmhJY1YMRnybCT8Za7lqbCg2YjXmO7iQyxffP2IpHTmk4UA== | |
X-Spam-Status: | No, score=-12.3 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, |
KAM_LAZY_DOMAIN_SECURITY, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE, | |
TXREP autolearn=no autolearn_force=no version=3.4.2 | |
X-Spam-Checker-Version: | SpamAssassin 3.4.2 (2018-09-13) on |
server2.sourceware.org | |
X-BeenThere: | cygwin AT cygwin DOT com |
X-Mailman-Version: | 2.1.29 |
List-Id: | General Cygwin discussions and problem reports <cygwin.cygwin.com> |
List-Unsubscribe: | <http://cygwin.com/mailman/options/cygwin>, |
<mailto:cygwin-request AT cygwin DOT com?subject=unsubscribe> | |
List-Archive: | <https://cygwin.com/pipermail/cygwin/> |
List-Post: | <mailto:cygwin AT cygwin DOT com> |
List-Help: | <mailto:cygwin-request AT cygwin DOT com?subject=help> |
List-Subscribe: | <http://cygwin.com/mailman/listinfo/cygwin>, |
<mailto:cygwin-request AT cygwin DOT com?subject=subscribe> | |
Reply-To: | cygwin AT cygwin DOT com |
Errors-To: | cygwin-bounces AT cygwin DOT com |
Sender: | "Cygwin" <cygwin-bounces AT cygwin DOT com> |
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 AT cygwin DOT 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 AT 2768 calls AT 2781 >>> nlsfuncs.cc(__set_locale_from_locale_alias)@1462 >>> which opens /usr/share/locale/locale DOT alias AT 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 AT 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
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |