On 16 Jan 2017 04:01, Icenowy Zheng wrote:
> When dealing lines with only a Chinese full-width punctuation or Japanese kana
> and locale is zh_CN.UTF-8, uniq command will consider all the lines are the
> same, and wrongly removed different punctuations.
this is a problem with glibc, not
Thanks for the heads-up. Rather than add that tzset call, which is a bit of a
hack, I'd rather make parse_datetime2 more reentrant so that it's immune to this
problem. So I installed this:
http://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=4e6e16b3f43ce96302b1e52e48730c1f15e18c14
into
Alain Knaff wrote:
$ LC_ALL=C.UTF-8 chmod 0
chmod: cannot access ‘’: 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
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
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
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
