[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GNUlib unicode encoding causes smart quotes to be displayed in progr
Re: GNUlib unicode encoding causes smart quotes to be displayed in program's output
Sat, 7 Dec 2019 12:19:01 +0000
Mozilla/5.0 (X11; Linux x86_64; rv:70.0) Gecko/20100101 Thunderbird/70.0
On 07/12/2019 04:10, Bruno Haible wrote:
Wes Hurd wrote:
What I meant about smart quotes being dangerous was, if copying the output
text that contains smart quotes to use somewhere else (especially in code),
the smart quotes have to be manually replaced which is tedious for the user
It's quite the opposite: The smart quote characters are safer because they
don't interfere with the quoting of a shell or programming language. For
example, in my music directory, I have a directory T’pau.
$ ls T’pau
China in your hand.wav
If the directory was named T'pau and I were to write the command
$ ls T'pau
it would hang. And
$ ls 'T'pau'
would hang as well. *This* is dangerous.
The user may not even see that smart quotes are being used unless there is
a breaking error.
But the smart quotes look different than an apostrophe! No confusion is
Your argument was correct 40 years ago, when
1. the shape of the apostrophe was given by US-ASCII and was not vertical
2. a character cell had so few pixels in height and width that smart quotes
and apostrophes could not be rendered differently.
The reason why quotearg.c uses smart quotes is explained in .
Agreeing with Bruno here.
Note gnulib supports shell quoting, which coreutils uses to safely quote file
Also coreutils ls leverages this to safely output file names by default.
Note also re apostrophe, word boundaries may be a consideration.
As I previously tweeted:
It's awkward for file names to use shell quote
It’s awkward for word regex to use right quote (\u2019)
Itʼs best to use apostrophe modifier (\u02BC)
Re: GNUlib unicode encoding causes smart quotes to be displayed in program's output, Paul Eggert, 2019/12/05