GNU bug report logs - #51832
Piping unicode text in `shell-command'

Previous Next

Full log

View this message in rfc822 format

From: Daniel Martín <mardani29 <at> yahoo.es>
To: Philipp <p.stephani2 <at> gmail.com>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 51832 <at> debbugs.gnu.org, tor.a.s.kringeland <at> ntnu.no, Alan Third <alan <at> idiocy.org>
Subject: bug#51832: Piping unicode text in `shell-command'
Date: Sun, 14 Nov 2021 16:01:17 +0100

Philipp <p.stephani2 <at> gmail.com> writes:

>> Am 14.11.2021 um 14:41 schrieb Lars Ingebrigtsen <larsi <at> gnus.org>:
>> 
>> Alan Third <alan <at> idiocy.org> writes:
>> 
>>> I've attached a patch that may do something towards preventing this
>>> problem but ultimately this is a convenience to give a best guess at
>>> choosing the correct dictionary, date format, etc. If we can't easily
>>> fix it then we can drop it and tell people to set it in their init.el
>>> themselves.
>> 
>> That didn't fix the issue for me, I'm afraid -- with that patch, LANG is
>> still the invalid en_NO.UTF-8 for me.
>
> Maybe we should add similar logic as iTerm2
> (https://github.com/gnachman/iTerm2/blob/79aff4d59fd591e7628649bcabe5f27541740bf6/sources/PTYSession.m#L7107):
> create the locale identifier from language code and country code
> instead of the current locale identifier, and use setlocale (or
> better, newlocale) to check whether it's valid, and fall back to
> en_US.UTF-8 otherwise?

Native macOS Terminal also has similar logic that calls setlocale.  It
tries to setlocale on LC_ALL (first argument 0) with these locale
identifiers in turn, until one of them succeeds:

- "localeIdentifier.UTF-8"
- "languageCode_countryCode.UTF-8"
- "languageCode_countryCode"

So they seem to give preference to [[NSLocale currentLocale]
localeIdentifier] and only use "languageCode_countryCode" as fallback.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.