From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from conssluserg-06.nifty.com (conssluserg-06.nifty.com [210.131.2.91]) by sourceware.org (Postfix) with ESMTPS id 6F369386F824 for ; Sun, 7 Jun 2020 09:23:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 6F369386F824 Received: from Express5800-S70 (v038192.dynamic.ppp.asahi-net.or.jp [124.155.38.192]) (authenticated) by conssluserg-06.nifty.com with ESMTP id 0579NIAQ009598 for ; Sun, 7 Jun 2020 18:23:18 +0900 DKIM-Filter: OpenDKIM Filter v2.10.3 conssluserg-06.nifty.com 0579NIAQ009598 X-Nifty-SrcIP: [124.155.38.192] Date: Sun, 7 Jun 2020 18:23:27 +0900 From: Takashi Yano To: cygwin@cygwin.com Subject: Re: cygwin-3.1.0 and mintty from desktop shortcut Message-Id: <20200607182327.9e291a5947adad7ca418204e@nifty.ne.jp> In-Reply-To: <20200607164252.600bf8b688d2f543dc12f373@nifty.ne.jp> 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> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.30; i686-pc-mingw32) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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@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: Sun, 07 Jun 2020 09:23:40 -0000 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. -- Takashi Yano