bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Tilde (~) in bash(1) is typeset incorrectly as Unicode character


From: Chet Ramey
Subject: Re: Tilde (~) in bash(1) is typeset incorrectly as Unicode character
Date: Fri, 28 Jul 2023 15:15:48 -0400
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.13.0

On 7/26/23 11:35 AM, G. Branden Robinson wrote:
Hi Thomas,

At 2023-07-26T10:47:05+0200, Thomas ten Cate wrote:
In the bash manual page (`man bash`), the ASCII tilde character '~'
(0x7e) is replaced by the Unicode character '˜' (U+02DC SMALL TILDE):

     $ man bash | grep 'additional binary operator'
                   An additional binary operator, =˜, is available,

The same happens for the use of ~ as a shorthand for the home
directory. This makes the manual page incorrect, and difficult to
search.

It looks like there is an ASCII tilde character in the man page's
source code:

     $ gunzip -c /usr/share/man/man1/bash.1.gz | grep 'additional
binary operator'
     An additional binary operator, \fB=~\fP, is available, with the same

I don't know the first thing about groff, but `man groff_char`
suggests that ~ is indeed rendered as "modifier tilde", and that one
should write \(ti to obtain an actual tilde character.

I know a little about groff.  Your advice is fine for man pages that
target only groff[1] and/or mandoc[2], but not Heirloom Doctools
troff,[3] neatroff[4] or Plan 9 troff (in its original form or as
maintained in Plan 9 from User Space[5]), and not legacy implementations
descended from AT&T troff that are, as far as I can tell, unmaintained
by the few Unix System V vendors that still exist.[6][7]

Many projects don't need to worry about such extreme portability in
their man pages, but GNU Bash arguably does.  (I'm open to correction.)

Furthermore, in the *roff language itself, as originally implemented by
Joe Ossanna (and re-implemented by Brian Kernighan) there is no good
way to test for the existence of a special character.[8]

As a first stab at it, I'd divide the world into two camps: (a) groff
and mandoc(1), and (b) everything else, and not worry about (b).

The bash(1) man page has an extensive preamble already that still
includes a workaround for 4.3BSD(!), so adding a little bit to it to
accommodate systems developed since 1990 might not be too disruptive.

I'm attaching a straw man diff to the bash(1) page.  If Chet likes it,
I'm happy to prepare one against the bash devel branch.

Applying the patch without any other changes to bash.1 results in

$ groff -Tascii -P -c -I/usr/local/src/bash/bash-20230728/doc -man /usr/local/src/bash/bash-20230728/doc/bash.1 > bash.0 troff: /usr/local/src/bash/bash-20230728/doc/bash.1:26: warning: numeric expression expected (got a special character)

Where line 26 is the

.if \n(.g:(\(.f=0) \{\

test. This is macOS running groff-1.22.4 from MacPorts.

Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]