From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.12]) by sourceware.org (Postfix) with ESMTPS id 4A0DC38708FC for ; Mon, 8 Jun 2020 19:24:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 4A0DC38708FC Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=SystematicSw.ab.ca Authentication-Results: sourceware.org; spf=none smtp.mailfrom=brian.inglis@systematicsw.ab.ca Received: from [192.168.1.104] ([24.64.172.44]) by shaw.ca with ESMTP id iNNfjW55O62briNNgjCC6K; Mon, 08 Jun 2020 13:24:24 -0600 X-Authority-Analysis: v=2.3 cv=LKf9vKe9 c=1 sm=1 tr=0 a=kiZT5GMN3KAWqtYcXc+/4Q==:117 a=kiZT5GMN3KAWqtYcXc+/4Q==:17 a=IkcTkHD0fZMA:10 a=w_pzkKWiAAAA:8 a=ZYZbmp4BlJBAQ5eLwdMA:9 a=QEXdDO2ut3YA:10 a=sRI3_1zDfAgwuvI8zelB:22 a=pHzHmUro8NiASowvMSCR:22 a=Ew2E2A-JSTLzCXPT_086:22 Reply-To: cygwin@cygwin.com Subject: Re: cygwin-3.1.0 and mintty from desktop shortcut To: cygwin@cygwin.com References: <87pngmx26z.fsf@Rainer.invalid> <20191218090415.GG10310@calimero.vinschen.de> <87a77pbn5j.fsf@Rainer.invalid> <87blp2lr6p.fsf@Rainer.invalid> <20200311195142.GH4042@calimero.vinschen.de> <87d09htlac.fsf@Rainer.invalid> <20200313100325.fe62798353f4c719ecf565e0@nifty.ne.jp> <87v9k4e8zz.fsf@Otto.invalid> <20200607103528.2eaea7de72b0afaa43d0b335@nifty.ne.jp> <20200607164252.600bf8b688d2f543dc12f373@nifty.ne.jp> <20200607182327.9e291a5947adad7ca418204e@nifty.ne.jp> <17858277-929a-2652-b584-67dc71a7706b@SystematicSw.ab.ca> <20200608192739.5becd75210bbc3696120ace2@nifty.ne.jp> From: Brian Inglis Autocrypt: addr=Brian.Inglis@SystematicSw.ab.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: <02cb5a43-0a0b-6c33-fa78-88fc387b63bd@SystematicSw.ab.ca> Date: Mon, 8 Jun 2020 13:24:22 -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: <20200608192739.5becd75210bbc3696120ace2@nifty.ne.jp> Content-Type: text/plain; charset=utf-8 Content-Language: en-CA Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfP54giqlMNoWzkuGWCV9OPZ62gqR10R8i254tRjxsJjpooZJxBEXgtuFrtSO1lkjpiwnczAAwO7lL7sd3x0qHttgn8rPXoKXQNRWhaOSBw3n77bxrduG ftMet2y69uA4FdOrknMyxSB/RfLK+4ZDgsIr6+DiuUCFvQlI8t+fw1XrTNElZi5T8uAE3nprziuS7w== X-Spam-Status: No, score=-12.3 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, 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@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2020 19:24:26 -0000 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 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.]