GNOME Bugzilla – Bug 79911
gfloppy and control-center help don't work
Last modified: 2004-12-22 21:47:04 UTC
Click on gfloppy help button: "/bin/bash: gnome-help: command not found" No yelp, no nothin'.
Now I don't even get that error. Just nothing happens.
triaging in line with all the other help problems.
Okay, I'm pretty sure this is a problem with libgnome::gnome-help API, but I can't test this on my machine because it doesn't get built :( CC'ing the relevant Help GURU's ;)
by looking at your error it looks like you don't have yelp correctly installed (or not in PATH) since you get the error: ""/bin/bash: gnome-help: command not found""
Yelp's installed in PATH, so that's not it. Don't know what other possibilities there are, so if you can suggest some other explanation for yelp not being installed correctly I'll check it out.
I'll also point out that the "/bin/bash: gnome-help: command not found" error no longer occurs. Now simply nothing happens at all when clicking on the help button.
Hmm .. that's weird, I figure that for some reason libgnome doesn't find it? Is this the only document this happens for? You seem to have things working with other documents?
The problem that Nothing happens is that they don't care about the error-value when calling gnome_help_display (last argument is passed in NULL). Sending in a GError and displaying it in a dialog show this: "Failed to execute child process "gnome-help" (No such file or directory)"
ok, so it's a PATH-problem. Setting the ghelp-uri handler to /gnome/head/INSTALL/bin/gnome-help instead of just gnome-help solved the problem with the gfloppy document. Not sure why it doesn't work with relative path for that program and others, should be investigated more.
Is this a 2.0.0 level problem? i.e., are a lot of users who aren't custom installing/building stuff into all kinds of weird prefixes going to see this? Can we punt to 2.0.1 if that is not going to be the case?
since we don't know what's causing it I'd say it's probably a gnome2-problem but it can probably be moved into gfloppy since that is the only application I've seen that this happens for.
Are there other apps that have a help *button* that are known to work?
dunno, are there other applications that has a Help *button*? if so, which one. From what I can see it doesn't really call the help-stuff in libgnome in any other way than it is being done from an application having it in the menu.
All the control-center dialogs have help buttons, and none of them seem to work (let alone be hooked up.)
ok, so, someone has to take a look on what's different between using gnome_help_display and GNOMEUI_HELP_CONTENTS ("...") or whatever that macro was called.
Jacob, could you take a look at this, please?
well i don't have a computer that can run gfloppy, but i can try to look into it. the older reports of gnome-help might have been because yelp didn't supply a gnome-help binary before, or something like that. jody recently hooked up the help buttons, but i don't think the docs exist. anyway enough FUD i'll look into i ;)
CCing myself as I am taking care of #73312.
Adding an error dialog in case we cannot display help.
Fixed on CVS. Please file individual bug reports for the capplets if there is need for them.
I'm going to reopen this. I'm fine if we want to move it to post-2.0, but the underlying problem - that help doesn't work on gfloppy if it's installed under a goofy prefix - is still there. The goofy prefix *is* in my PATH, so the GNOME help functions ought to be able to find it. I can use gconf-editor to fix the path for gnome-help, but I don't think we should expect users to figure that out.
Jfleck, in your setup: - Where is libgnome installed? - Where is yelp installed? - Where is gfloppy installed?
In all three cases, they're installed with vbs under the same prefix: ~/gnome/head/INSTALL, so the executables are in ~/gnome/head/INSTALL/bin and the library is under ~/gnome/head/INSTALL/lib.
And ~/gnome/head/INSTALL/bin is in your PATH. What error dialog does gfloppy bring up?
Until I set the ghelp-uri handler to explicitly call ~/gnome/head/INSTALL/bin/gnome-help instead of just gnome-help (as Mikael suggested above), I got your new dialog telling me that it couldn't find gnome- help. And yes, ~/gnome/head/INSTALL/bin is in my PATH.
For testing purposes, it would be great if you could please do the following: 1. Unset the ghelp uri handler. 2. Could you please run gfloppy under gdb and break in gnome_url_show()? I'd like to see the contents of the argv array just before it calls g_spawn_async(). Also, could you please look at the environment at that point? ("show env" in gdb) It would be useful to see the contents of $PATH there.
In gdb, I broke at line 341, where it makes the gnome_help_display call (I couldn't find "gnome_url_show"). From "show env" in the debugger: PATH=/home/jfleck/gnome/head/INSTALL/bin:/usr/local/bin:/bin:/usr/bin :/usr/X11R6/bin:/home/jfleck/bin (gdb) print argv $1 = (char **) 0xbffff9a4
Unfortunately this is not enough information. When can I catch you on irc to guide you through the debug process?
So... I'm unclear on the status here- is this just a gfloppy specific bug now, or is it still a general problem?
OK, this is really weird. Tracing through the fork()ed grandchild process and breaking in g_execute() shows that the call to g_getenv("PATH") is yielding $PATH:/sbin:/usr/sbin:/usr:/usr/bin as a result. E.g. what you get is bogus; there should be no shell variable crap in there. According to jfleck, #83068 could be related and it seems like Gman is getting that as well. I don't know if it is some misconfiguration in jfleck's machine or something; I have no clue where the child process would be getting that PATH from. CCing Gman to see if we can get any more info on this.
Ignore the above; just found the bug. gfloppy does putenv("PATH=$PATH:...") in main.c:100. Will fix in a second.
Fixed on CVS. Please update your gnome-utils.