GNU bug report logs -
#25495
WTF? Chmod (and presumably other coreutils) corrupt their own error messages with "smart" quotes...
Previous Next
Reported by: Alain Knaff <alain <at> knaff.lu>
Date: Fri, 20 Jan 2017 21:45:02 UTC
Severity: normal
Done: Paul Eggert <eggert <at> cs.ucla.edu>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 25495 in the body.
You can then email your comments to 25495 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-coreutils <at> gnu.org:
bug#25495; Package
coreutils.
(Fri, 20 Jan 2017 21:45:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Alain Knaff <alain <at> knaff.lu>:
New bug report received and forwarded. Copy sent to
bug-coreutils <at> gnu.org.
(Fri, 20 Jan 2017 21:45:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
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).
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.
Who came up with this? :-)
Thanks for fixing this,
Alain
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#25495; Package
coreutils.
(Fri, 20 Jan 2017 22:34:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 25495 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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
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
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
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?
>
> Who came up with this? :-)
Coreutils has been doing this for years.
>
> Thanks for fixing this,
It's not obvious what needs to be fixed, without more details from your end.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#25495; Package
coreutils.
(Fri, 20 Jan 2017 23:00:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 25495 <at> debbugs.gnu.org (full text, mbox):
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
Reply sent
to
Paul Eggert <eggert <at> cs.ucla.edu>:
You have taken responsibility.
(Sat, 21 Jan 2017 00:03:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Alain Knaff <alain <at> knaff.lu>:
bug acknowledged by developer.
(Sat, 21 Jan 2017 00:03:02 GMT)
Full text and
rfc822 format available.
Message #16 received at 25495-done <at> debbugs.gnu.org (full text, mbox):
Alain Knaff wrote:
> $ LC_ALL=C.UTF-8 chmod 0 ffff
> chmod: cannot access ‘ffff’: No such file or directory
It looks like you're using an old version of coreutils. The current version
outputs ASCII apostrophes there. This was a change committed on 2015-11-04 and
released in coreutils 8.25; it makes it easier to cut and paste file names from
diagnostics into shells.
Since the reported behavior is already fixed I'm taking the liberty of closing
the bug report.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Sat, 18 Feb 2017 12:24:03 GMT)
Full text and
rfc822 format available.
This bug report was last modified 8 years and 124 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.