bug#25495: WTF? Chmod (and presumably other coreutils) corrupt their own error messages with "smart" quotes...

[Alain Knaff]

On 01/20/2017 23:33, Eric Blake wrote:
> On 01/20/2017 03:44 PM, Alain Knaff wrote:
>> Hi,
>>
>> Recently, while browsing error mails of some cron jobs, I noticed that
>> chmod puts "smart" quotes into its error messages.
>>
>> IMHO, such gimmicks should have no place in core utilities.
>>
>> At least this behavior should be optional via configuration or
>> environment setting (preferably off by default).
> 
> It IS configurable by environment variables: set LC_ALL=C as a

Doesn't help, as long as I still need UTF-8:

$ LC_ALL=C.UTF-8 chmod 0 ffff
chmod: cannot access ‘ffff’: No such file or directory


With just C, it does indeed work:

> LC_ALL=C  chmod 0 ffff
chmod: cannot access 'ffff': No such file or directory

... but in that case, I'd get (obviously...) trouble getting proper
alignment in ls or vi when working with data containing unicode characters.


> sledgehammer to turn it (and all other localization aspects) off.  You
> can also use LC_MESSAGES and fine-tune the creation of a custom one-off

LC_MESSAGES doesn't do anything (if set to C):

$ LC_MESSAGES=C  chmod 0 ffff
chmod: cannot access ‘ffff’: No such file or directory

... or is C only for LC_ALL, and LC_MESSAGES needs a different value?

> locale if you don't like the behavior of your current locale.
> 
>>
>> The faulty code lives in lib/quotearg.c in function gettext_quote
>>
>> Even defining a custom locale that just maps quotes to themselves
>> doesn't work, because this function specifically tests for that case
>> (translation same as msgid), and then "manually" garbles the quotes.
> 
> Can you please paste an example of something that's actually garbled? Or

See examples above... or again:

$ chmod 0 ffff
chmod: cannot access ‘ffff’: No such file or directory



> is this merely a case of you mixing locales (where the coreutils are
> producing output in one locale/encoding, but your other tools are
> post-processing the data in another locale/encoding), where the garbling
> is a result of your mismatched locales?

Nope, it also happens with just coreutils alone.

> 
>>
>> Who came up with this? :-)
> 
> Coreutils has been doing this for years.
> 

Ok, so you've managed to sneak this past us for some years. Still
doesn't make it right :-(

>>
>> Thanks for fixing this,
> 
> It's not obvious what needs to be fixed, without more details from your end.
> 

Regards,

Alain