bug#51832: Piping unicode text in `shell-command'

[Daniel Martín]

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

>> Am 14.11.2021 um 14:41 schrieb Lars Ingebrigtsen <larsi@gnus.org>:
>> 
>> Alan Third <alan@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.