X-Recipient: archive-cygwin AT delorie DOT com DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 594893851C01 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com; s=default; t=1591612077; bh=+kMqQopFaw09V13R0JgP8/op/jdMIpw5Orkfv3+sAUk=; h=Date:To:Subject:In-Reply-To:References:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=V3Gvy3RIsIh72BEm5wTNFZi6X/N4rlf7ekGtEZXo5N1I2/WDMPGjTc14Pqmc4Q+ZP FT1nB06Y1G+TXLlhBcqVC77+FkX2qom5V8Et98Q8COqHgLSx9eKuVNQEy/7kP88Qfi snjBfFLQGOc8PTMqQ0YPuTSLjWILB4F1QTn3pOFM= X-Original-To: cygwin AT cygwin DOT com Delivered-To: cygwin AT cygwin DOT com DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 73AAB3851C3D DKIM-Filter: OpenDKIM Filter v2.10.3 conssluserg-04.nifty.com 058ARUXj017959 X-Nifty-SrcIP: [124.155.38.192] Date: Mon, 8 Jun 2020 19:27:39 +0900 To: cygwin AT cygwin DOT com Subject: Re: cygwin-3.1.0 and mintty from desktop shortcut Message-Id: <20200608192739.5becd75210bbc3696120ace2@nifty.ne.jp> In-Reply-To: <17858277-929a-2652-b584-67dc71a7706b@SystematicSw.ab.ca> References: <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> <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> <20200607164252 DOT 600bf8b688d2f543dc12f373 AT nifty DOT ne DOT jp> <20200607182327 DOT 9e291a5947adad7ca418204e AT nifty DOT ne DOT jp> <17858277-929a-2652-b584-67dc71a7706b AT SystematicSw DOT ab DOT ca> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.30; i686-pc-mingw32) Mime-Version: 1.0 X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, 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 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Takashi Yano via Cygwin Reply-To: Takashi Yano Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: cygwin-bounces AT cygwin DOT com Sender: "Cygwin" 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 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(). 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 -- 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