On Fri, Apr 17, 2020 at 03:05:06PM +0200, Ingo Schwarze wrote:
> Naively, it does seem like it would make sense to have "locale -m"
> print a list of possible output values of "locale chardef", so i'm
> not opposed to adding "US-ASCII" to it. But that doesn't appear to
> be how it works
Hi Stefan and Todd,
Stefan Sperling wrote on Fri, Apr 17, 2020 at 08:55:29AM +0200:
> On Thu, Apr 16, 2020 at 09:35:18PM +0200, Ingo Schwarze wrote:
>>$ locale -m
>> UTF-8
>>$ locale charmap
>> UTF-8
>>$ LC_ALL=C locale charmap
>> US-ASCII
>>$ LC_ALL=POSIX locale charmap
>>
On Thu, Apr 16, 2020 at 09:35:18PM +0200, Ingo Schwarze wrote:
>$ locale -m
> UTF-8
>$ locale charmap
> UTF-8
>$ LC_ALL=C locale charmap
> US-ASCII
>$ LC_ALL=POSIX locale charmap
> US-ASCII
I am OK with your diff, and noticed a separate issue with -m which
is exposed by
Makes sense to me. OK millert@
- todd
Hi,
our locale(1) implementation is intentionally simplistic
and implements only a subset of this POSIX specification:
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/locale.html
However, one feature is missing that is actually useful and arguably
also well-placed inside the
