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

[Philipp]

> Am 14.11.2021 um 11:31 schrieb Eli Zaretskii <eliz@gnu.org>:
> 
>> From: Lars Ingebrigtsen <larsi@gnus.org>
>> Cc: tor.a.s.kringeland@ntnu.no,  51832@debbugs.gnu.org,  alan@idiocy.org
>> Date: Sun, 14 Nov 2021 10:46:05 +0100
>> 
>>  NSLocale *locale = [NSLocale currentLocale];
>> 
>>  NSTRACE ("ns_init_locale");
>> 
>>  @try
>>    {
>>      /* It seems macOS should probably use UTF-8 everywhere.
>>         'localeIdentifier' does not specify the encoding, and I can't
>>         find any way to get the OS to tell us which encoding to use,
>>         so hard-code '.UTF-8'.  */
>>      NSString *localeID = [NSString stringWithFormat:@"%@.UTF-8",
>>                                     [locale localeIdentifier]];
>> 
>>      /* Set LANG to locale, but not if LANG is already set.  */
>>      setenv("LANG", [localeID UTF8String], 0);
>>    }
>> 
>> And...  it's a Macos bug?  Googling a bit seems to say that this does
>> indeed return invalid locale identifiers -- just language glued together
>> with the country, resulting in identifiers that doesn't match any
>> locales the OS knows about.
>> 
>> So...  I don't know what to do about that.  Is there a way to check that
>> the identifier is valid?
> 
> I asked once why we push LANG into the environment, instead of calling
> setlocale, which would only affect Emacs.  I don't think I saw an
> answer to that question, or did I miss it?
> 

AIUI the intention is that this should affect subprocesses started from Emacs.  
At least that's how I interpret the comment

/* macOS doesn't set any environment variables for the locale when run
   from the GUI. Get the locale from the OS and set LANG.  */