Bug#548844: lintian: hyphen-used-as-minus-sign generating false positives?
Charles Plessy <plessy@debian.org> writes:
> I have just checked at manual pages that triggers
> hyphen-used-as-minus-sign informational reports, like samtools(1) for
> instance, and I did not experience any problem in searching for the
> minus sign. I wonder if hyphen-used-as-minus-sign is not massively
> triggering false positives, in the sense that not backslashing minus
> signs do not create problems for the user.
> I have seen problems for long options where two minus signs were
> converted in en hyphens, so the test still has some uses, but
> shouldn't be made much more conservative?
You're not seeing the problem because of the change in Debian's version of
groff as of 1.18.1.1-7:
* Too many fonts are missing the Unicode HYPHEN character, so I give up.
Render "-" as HYPHEN-MINUS (ASCII 0x2D) by default. (Of course, manual
pages using "-" when they should be using "\-" should still be fixed.)
Note the last statement. See also groff's README.Debian:
| If you're using a UTF-8 locale and are having problems searching for
| dashes in man pages such as those in command-line options, this may be
| because the man page uses "-" rather than "\-" to represent them, so
| they get rendered as a Unicode hyphen which isn't the one you can type
| conveniently on your keyboard. These man pages should be fixed. However,
| you can make groff use a plain ASCII dash in this case by editing both
| /etc/groff/man.local and /etc/groff/mdoc.local and uncommenting the
| final request, so that it looks like this:
|
| . \" Debian: Many UTF-8 man pages use "-" instead of "\-" for dashes such
| . \" as those in command-line options. This is a bug in those pages, but
| . \" too many fonts are missing the Unicode HYPHEN character, so we render
| . \" this as the ASCII-compatible HYPHEN-MINUS instead.
| . if '\*[.T]'utf8' \
| . char - \N'45'
|
| As of groff 1.18.1.1-7, this defaults to being uncommented. You can
| comment it out again if you want to make sure that man pages you're
| writing are clear of this problem.
The tag is already very conservative in the sense that it's only
info-level. By the semantics of the *roff language, the man pages really
are wrong and need to be fixed, and they will render incorrectly, with all
the accompanying problems, on other systems such as Red Hat that don't
have this local modification to an.tmac.
I suspect that at some point this change in groff should be reverted and
should return to the upstream behavior since fonts these days are much
more likely to have that Unicode code point available.
I'll clarify the Lintian tag description to add a pointer to this
statement and explain why people don't see problems currently on
default-configurd Debian systems.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: