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

Previous Next

Full log

View this message in rfc822 format

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Philipp <p.stephani2 <at> gmail.com>
Cc: 51832 <at> debbugs.gnu.org, Alan Third <alan <at> idiocy.org>, Eli Zaretskii <eliz <at> gnu.org>, tor.a.s.kringeland <at> ntnu.no
Subject: bug#51832: Piping unicode text in `shell-command'
Date: Sun, 14 Nov 2021 15:28:02 +0100

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

>> 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,

I think that's what's Macos is returning -- it's just concatenating
those two codes to get a locale identifier.  (Which is wrong, of
course.)

> and use setlocale (or better, newlocale) to check whether it's valid,

Yes, that sounds good.

> and fall back to en_US.UTF-8 otherwise?

Hm...  I'd rather just leave LANG unset in that case -- it'll probably
lead to fewer glitches, I think.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

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