GNOME Bugzilla – Bug 648854
yelp cannot display any man pages due to calling /usr/bin/man with bogus -Z command-line option
Last modified: 2018-05-22 12:54:53 UTC
Commit 46a82ade3e6f0fac8f08b18e7fc23d8665f6f728 (see http://git.gnome.org/browse/yelp/commit/libyelp/yelp-man-parser.c?id=46a82ade3e6f0fac8f08b18e7fc23d8665f6f728) replaced the good old, working man page parser in yelp with one that calls the man executable - and calls it incorrectly.
Namely: yelp now calls "man -Z -Tutf8 <path>".
Except that the standard Linux man command doesn't have the -Z command-line option. The latest version, man-1.6g (released in December 2010) doesn't recognize it. Neither does the previous version, man-1.6f (released in 2007).
Perhaps Fedora is using some strange customized version of the man command that does recognize -Z. If so, I would humbly suggest that Fedora devs work on getting their changes accepted by the man upstream before breaking yelp for users of other distros.
Because currently, trying to use yelp to view a man page with the standard Linux man command installed results in the following error message:
man: invalid option -- 'Z'
man, version 1.6g
usage: man [-adfhktwW] [section] [-M path] [-P pager] [-S list]
[-m system] [-p string] name ...
a : find all matching entries
c : do not use cat file
d : print gobs of debugging information
D : as for -d, but also display the pages
f : same as whatis(1)
h : print this help message
k : same as apropos(1)
K : search for a string in all pages
t : use troff to format pages for printing
w : print location of man page(s) that would be displayed
(if no name given: print directories that would be searched)
W : as for -w, but display filenames only
C file : use `file' as configuration file
M path : set search path for manual pages to `path'
P pager : use program `pager' to display pages
S list : colon separated section list
m system : search for alternate system's man pages
p string : string tells which preprocessors to run
e - [n]eqn(1) p - pic(1) t - tbl(1)
g - grap(1) r - refer(1) v - vgrind(1)
Right, this is my fault. I'll have a look and try to work out how to fix this problem at the weekend: I'm at a conference at the moment.
Incidentally, this particular "Fedora dev" uses Debian, which seemingly has the same man-db.
Also, the "good old, working man page parser in yelp" was crappy and mostly *didn't* work, which is why we stripped it out. Anyhow, hopefully there will be a good solution soon.
Hmm, I've just downloaded the vanilla man's source and read through it's manpage. It seems we'll have to do this by calling (g)roff directly on systems that don't have man-db. See https://bugzilla.gnome.org/show_bug.cgi?id=477788 for why I was trying to avoid doing that.
Sigh, damned if we do, damned if we don't. I am so tired of man.
Well, it should be an easy enough test. I'll try to code something up this weekend.
Created attachment 187006 [details] [review]
patch for compatibility with vanilla man
I apologize for the tone of my message above. I now understand the reasons for removing the original parser, and agree that it was the correct thing to do.
Here is a patch that allows yelp to work on systems without man-db. It adds a small shell script that tries to call "man -Z -Tutf8 -EUTF-8 [FILE]", and if that fails, uncompresses the file and pipes it into "groff -t -man -Z -Tutf8". (IMHO, a shell script is the right tool for this because it lends itself to easy modification on systems with weird man setups.)
With this patch, yelp correctly opens man files on my machine that has man-1.6g and groff-1.21 installed.
This looks like a good way to do things. I wondered for a while whether sticking stuff in libexec was right, but I've convinced myself it makes sense...
Shaun: Would this approach be ok? The other easily-customisable-by-distros option I thought of was some registry key containing the correct pipeline. But that's not as good because of compressed man-pages, which need treating separately for each type. Bleugh.
Any news on this? (we are needing to carry this patch for ages and it would be interesting to stop needing to do that :))
-- GitLab Migration Automatic Message --
This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.
You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/yelp/issues/50.