After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 648854 - yelp cannot display any man pages due to calling /usr/bin/man with bogus -Z command-line option
yelp cannot display any man pages due to calling /usr/bin/man with bogus -Z c...
Product: yelp
Classification: Applications
Component: Man Pages
Other Linux
: Normal major
: ---
Assigned To: Yelp maintainers
Yelp maintainers
Depends on:
Reported: 2011-04-28 08:47 UTC by Alexandre Rostovtsev
Modified: 2018-05-22 12:54 UTC
See Also:
GNOME target: ---
GNOME version: ---

patch for compatibility with vanilla man (4.13 KB, patch)
2011-05-02 03:55 UTC, Alexandre Rostovtsev
none Details | Review

Description Alexandre Rostovtsev 2011-04-28 08:47:24 UTC
Commit 46a82ade3e6f0fac8f08b18e7fc23d8665f6f728 (see 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)
Comment 1 Rupert Swarbrick 2011-04-28 12:54:33 UTC
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.

Comment 2 Rupert Swarbrick 2011-04-28 13:00:29 UTC
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 for why I was trying to avoid doing that.

Comment 3 Shaun McCance 2011-04-28 13:38:15 UTC
Sigh, damned if we do, damned if we don't. I am so tired of man.
Comment 4 Rupert Swarbrick 2011-04-28 14:12:00 UTC
Well, it should be an easy enough test. I'll try to code something up this weekend.
Comment 5 Alexandre Rostovtsev 2011-05-02 03:55:29 UTC
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.
Comment 6 Rupert Swarbrick 2011-05-03 10:21:10 UTC
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.
Comment 7 Pacho Ramos 2015-05-19 19:21:51 UTC
Any news on this? (we are needing to carry this patch for ages and it would be interesting to stop needing to do that :))

Comment 8 GNOME Infrastructure Team 2018-05-22 12:54:53 UTC
-- 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: