[FLAC 1.5.0-1] Man pages use HYPHEN character instead of HYPHEN-MINUS.

[Brian Inglis]

On 2026-02-04 12:03, Thomas Wolff via Cygwin wrote:
> Am 04.02.2026 um 18:10 schrieb Brian Inglis via Cygwin:
>> On 2026-02-04 02:56, Vincent via Cygwin wrote:
>>> My request is related to an issue I opened in the FLAC Github :
>>> https://github.com/xiph/flac/issues/861
>>>
>>> After some investigations, the issue is related to the build release of the
>>> FLAC package provided by Cygwin : the man pages of flac(1) and metaflac(1)
>>> use the HYPHEN (U+2010 )  character instead of the HYPHEN-MINUS (U+002D)
>>> character.
>>>
>>> These two commands expect HYPHEN-MINUS character, so if you copy-paste the
>>> man page options in your terminal, it will fail.
>>>
>>> Example : flac ‐‐version
>>> will return an error : « can't open input file ‐‐version: No such file or
>>> directory », because of  « ‐‐version » with HYPHEN copied-pasted from the
>>> man pages.
>>>
>>> The right string is « --version » with HYPHEN-MINUS (U+002D).
>>>
>>> Example : flac --version
>>> will return : « flac 1.5.0 »
>>>
>>> Please, feel free to read the issue in Github (
>>> https://github.com/xiph/flac/issues/861 ) for more details, as it's easier
>>> to read code and quotes with the markdown formatting.
>>>
>>> This is a very pretty nasty kind of bug, because it's very difficult to
>>> distinguish HYPHEN-MINUS and HYPHEN in a terminal. It's also very difficult
>>> to figure out why the command has failed, as the « No such file or
>>> directory » is not the root cause of the problem.
>>>
>>> I think a new build release to fix this, would be very welcome.
>>>
>>> Thank you very much for your time and your great work. :)
> It’s really a nuisance that man (presumably gnu man, but I don’t remember the 
> details of a previous discussion) changed interpretation of some important 
> characters into „glyphs“ that some witty people thought to be nice but are 
> completely non-functional.
> It applies not only to „-“ but also to „~“. Look at `man bash` and search for 
> bashrc and you'll see the tilde symbol replaced by an ugly superscript „small 
> tilde“. Why??
> Package maintainers are forced to adapt their man pages and either replace all 
> occurrences of these characters by corresponding escapes or apply these two 
> global tricks per man page:
> 
> .char ^ \(ha
> .char - \N'45'

It appears to be a consequence more of groff -man being upgraded to produce 
better quality typographic output more consistently with other macro packages, 
output devices, and more comprehensive font, character, and glyph sets, while 
not penalizing the other existing macro packages originally designed and 
intended to produce quality output: see groff(7), groff_rfc1345(7), and 
groff_char(7), for example:
"The developers of AT&T /troff/ chose mappings for them that would be useful for 
typesetting technical literature in a broad range of scientific disciplines
...
Keycap  Appearance and meaning   Special character and meaning
   "     " neutral double quote   \[dq] neutral double quote
   '     ’ closing single quote   \[aq] neutral apostrophe
   -     ‐ hyphen                 \- or \[-] minus sign/Unix dash
   \     (escape character)       \e or \[rs] reverse solidus
   ^     ˆ modifier circumflex    \(ha circumflex/caret/“hat”
   `     ‘ opening single quote   \(ga grave accent
   ~     ˜ modifier tilde         \(ti tilde"

Really this tension between compatibility with tty input and basic/draft and 
typographic quality output has existed since the earliest days of computerized 
text formatting and typesetting with various levels of higher quality output 
devices from dot matrix, daisy wheel, phototypesetter, electrostatic, laser, and 
higher quality rendering devices.

[Note: \N'#' refers to the current output font glyph index *NOT* an input code.]

>> Upstream sources seems to provide only .md man sources and no b-r package for 
>> conversion (pandoc unavailable from Cygwin) so man pages are generated for the 
>> upstream sources, and this conversion generates man page options with plain 
>> text hyphen-minus, which are treated by man as normal text *hyphen* `‐­­` not 
>> plain text *minus* `-`.
>> In man pages you use escaped hyphen-minus `\fB\-v\fR` to treat them as minus 
>> text `-` as used in options `-v`.
>> We see this use of unescaped hyphens in the upstream tar files, below, so 
>> please complain upstream about their man page generation, and reopen their issue:
>> ```
>> $ wget https://mirror.../x86_64/release/flac/flac-1.5.0-1-src.tar.xz
>> $ tar -xvf flac-1.5.0-1-src.tar.xz
>> flac-1.5.0-1.src/
>> flac-1.5.0-1.src/flac-1.5.0.tar.xz            # upstream sources
>> flac-1.5.0-1.src/FLAC.cygport
>> $ tar -xvf flac-1.5.0-1.src/flac-1.5.0.tar.xz flac-1.5.0/man/{,meta}flac.1
>> flac-1.5.0/man/flac.1
>> flac-1.5.0/man/metaflac.1
>> $ grep -m5 '\\f[[{]\?B[]}]\\\?-' flac-1.5.0/man/{,meta}flac.1
>> flac-1.5.0/man/flac.1:\f[B]-\f[R] \f[I]\&...\f[R] ]
>> flac-1.5.0/man/flac.1:\f[B]flac\f[R] [ \f[B]-d\f[R] | \f[B]--decode\f[R] | 
>> \f[B]-t\f[R] |
>> flac-1.5.0/man/flac.1:\f[B]--test\f[R] | \f[B]-a\f[R] | \f[B]--analyze\f[R] ] [
>> flac-1.5.0/man/flac.1:\f[I]infile.ogg\f[R] | \f[B]-\f[R] \f[I]\&...\f[R] ]
>> flac-1.5.0/man/flac.1:\f[B]-d\f[R], analysis with \f[B]-a\f[R] or testing with 
>> \f[B]-t\f[R].
>> flac-1.5.0/man/metaflac.1:\f[B]-o\f[R] \f[I]filename\f[R]\f[B], --output- 
>> name=\f[R]\f[I]filename\f[R]
>> flac-1.5.0/man/metaflac.1:\f[B]--preserve-modtime\f[R]
>> flac-1.5.0/man/metaflac.1:\f[B]--with-filename\f[R]
>> flac-1.5.0/man/metaflac.1:\f[B]--no-filename\f[R]
>> flac-1.5.0/man/metaflac.1:\f[B]--no-utf8-convert\f[R]
>> ```
-- 
Take care. Thanks, Brian Inglis              Calgary, Alberta, Canada

La perfection est atteinte                   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retrancher  but when there is no more to cut
                                 -- Antoine de Saint-Exupéry