GNOME Bugzilla – Bug 140951
yelp doesn't open man: and info: pages in gnome 2.6
Last modified: 2006-01-23 20:02:18 UTC
Distribution: Debian 3.0-bunk-2 Package: Yelp Severity: normal Version: GNOME2.6. HEAD Gnome-Distributor: GARNOME Synopsis: yelp doesn't open man: and info: pages in gnome 2.6 Bugzilla-Product: Yelp Bugzilla-Component: Help converters Bugzilla-Version: HEAD Description: Description of Problem: I upgraded from gnome 2.4.1 to gnome 2.6. Previously 'yelp man:man' opened the eaccording manpage. Now it yields omly an error message: "Das gewählte Dokument konnte nicht geöffnet werden" meaning the selected document could not be opened. I also miss the index searcn facility from previous yelp versions. Steps to reproduce the problem: 1. [schaefer@spike:schaefer] yelp man:man 2. 3. Actual Results: page does not open Expected Results: the info page, as in yelp 2.2.3 to 2.4.1 which still work on my system How often does this happen? always Additional Information: actually tested yelp versions 2.6.0 and 2.6.1 System uses debian stable with backports. the older versions had some man2html binary. this doesn't seem to be the case for the 2.6 binaries from garnome? [schaefer@spike:schaefer] locate man2html /export/sw/gnome/2.4.1/libexec/yelp-man2html /export/sw/gnome/garnome/share/sgml/docbook/yelp/man2html.xsl /usr/lib/libgnome2-0/gnome2-man2html ------- Bug moved to this database by unknown@bugzilla.gnome.org 2004-04-24 03:26 ------- Unknown platform unknown. Setting to default platform "Other". Unknown milestone "unknown" in product "Yelp". Setting to default milestone for this product, '---' Setting to default status "UNCONFIRMED". Setting qa contact to the default for this product. This bug either had no qa contact or an invalid one.
Created attachment 28182 [details] [review] A patch which enables relative man paths to work Here's a patch which makes the man: locations work for me in yelp. Actually, it already worked when I supplied the full path (i.e. 'yelp man:/usr/share/man/en/man1/man.1.gz'), so this patch just finds the path using 'man --path'. info:, on the other hand, isn't even checked for at all in the uri parsing. It could probably be added in a similar way to man: (if it hasn't been removed at a deeper level), but it doesn't seem to have an equivalent for 'man --path'. So there's at least a couple issues there... However, I thought I'd add the patch I had to find out if I was at least on the right track before going further...
Also, on a related note, why are yelp-man.[ch] and yelp-info.[ch] part of the source still if the only call to their functions (in yelp-base.c:yelp_base_new) has been commented out? Is it just part of a temporary transformation?
All right, two things: First, --path is a GNUism. Let's use -w instead. I don't know that it works on all systems, but it does work on both GNU and BSD. Second, all declarations have to be at the top of their respective blocks. Otherwise, people beat me for using C99.
Created attachment 28251 [details] [review] Remove GNUism and C99ism
*** Bug 145813 has been marked as a duplicate of this bug. ***
Hi, I was trying the above patch, but it doesn't work in some circumstances i.e. when a cat page exists when the output of man -w looks like this: ~ $ man -w man /var/cache/man/cat1/man.1.bz2 (<-- /usr/share/man/man1/man.1.gz) This can be gotten around by using man -wc instead: ~ $ man -wc man /usr/share/man/man1/man.1.gz I've attached another patch which implements this.
Created attachment 32072 [details] [review] Fixes earlier patch to return only true result
*** Bug 155295 has been marked as a duplicate of this bug. ***
We have the beginning of man and info support in CVS now, I think you have to enable it explicitly when configuring, but it's a start at least.
*** Bug 156530 has been marked as a duplicate of this bug. ***
Man and info support are enabled by default in CVS.