This is the source of the man page for openconnect(8):
I have no idea why the dashes therein are all "escaped" as \- instead of just a simple - character. I probably cargo-culted it from whatever man page I started with and stripped down.
As well as being shipped as a man page, the manual is also converted to xhtml (groff -t -K UTF-8 -mandoc -Txhtml) and included in the HTML documentation:
It seems that the "escaped" dashes end up being rendered into HTML as −, and thus I have received a complaint from a user that when copying from the browser and pasting into a command line, the options didn't work because he got U+2212 MINUS SIGN instead of U+002D HYPHEN-MINUS.
Should I just do a global 's/\-/-/' on the source file, or was there a *reason* for them being that way in a man page?
FWIW *every* other man page I've just looked at has also used \- instead of plain - in options. It wasn't just something odd that I made up :)
> I have no idea why the dashes therein are all "escaped" as \- instead of
> just a simple - character. I probably cargo-culted it from whatever man page
> I started with and stripped down.
implicitly groff renders '-' as a hyphen (U+2010) instead of ASCII 0x2D (minus).
> Should I just do a global 's/\-/-/' on the source file, or was there
> a *reason* for them being that way in a man page?
this will render - as - (at least on my machine), but groff upstream would prefer to user \- (as you can read in ). Even if it is working, I would not change it, all man pages from man-pages upstream uses \- for minus.
> It seems that the "escaped" dashes end up being rendered into HTML as −,
Yes, because - is minus sign. In order to give semantics to a symbol -, &minus entity is used instead of -. However, browser renders this symbol as U+2212. There is ­ entity, which represents 0x2D symbol (expected behaviour), but it is rendered as a blank symbol. However - is working.
You can run:
$ groff -t -K UTF-8 -mandoc -Txhtml manpage | sed 's/\−/\-/g'
As from , \- is still being replaced by U+2212. And from  it looks like the question is still not resolved.
cf. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=159872#54 in which Colin Watson points out that groff_char(7) says the following:
- the ISO Latin-1 `Hyphen, Minus Sign'
(code 45) prints as a hyphen; a minus sign
can be obtained with \-.
So if \- is supposed to be a minus sign, surely it is a bug that in UTF-8 terminal output it *isn't* being emitted as U+2212 MINUS SIGN?
Emitting U+002D HYPHEN-MINUS is wrong.
citing Colin's response:
"Firstly, it is not converted to em-dash. On the utf8 device, it is
converted to either Unicode HYPHEN (0x2010) or SOFT HYPHEN (0x00AD)
depending on context."
Depending on context is important.
Try the simplest example of hmtl:
and open it in a web browser. As you can see, the two lines has different width and look different. I believe upstream chooses U+2212 as it renders significantly better than the "correct" minus sign that can be copied one2one to terminal. Terminal and html are two different devices and thus requires two different mappings for \-.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
Thank you for reporting this bug and we are sorry it could not be fixed.