GNOME Bugzilla – Bug 155773
GnomeVFSMimeApplication command field contains spaces
Last modified: 2004-12-22 21:47:04 UTC
Here's the symptom: Firefox doesn't know about a lot of mime types. Drive firefox to a site that has tarballs on it. The web server will return a type of "application/x-tar". Firefox will pop up a dialog asking to save the file or use an application. Unfortunately, firefox never seems to know about the applications available. In the code firefox uses a pattern like this: GnomeVFSMimeApplication *handlerApp = gnome_vfs_mime_get_default_application(mime type); gchar *nativeCommand = g_filename_from_utf8(handlerApp->command, -1, NULL, NULL, NULL); gchar *commandPath = g_find_program_in_path(nativeCommand); Turns out that the commandPath is null. The nativeCommand string actually has a trailing space at the end of the command so it isn't found in the path. It probably shouldn't include the string.
*** This bug has been marked as a duplicate of 155386 ***
Blizzard: That code isn't right. command isn't a binary name, its a command line. It can be e.g. "command --argument". Also, i'm not sure why you are converting it from utf8. The commandline comes from a desktop file, so its likely to be in utf8, although its unlikely to have non-ascii characters. And in the case it *has* non-ascii characters its unlikely that the best thing to do is to look for different binaries depending on the current locale.
Btw. Why don't you use gnome_vfs_mime_application_launch, which does all the command line handling?
10:08 < halfline> blizzard: if you call g_shell_parse_argv() then you can look at argv[0] with g_find_program_in_path() 10:09 < halfline> blizzard: that should chomp the trailing space and handle the case where there are arguments in the command string 10:09 < halfline> blizzard: (arguments preceding the substitution variable, any after the substitution variable are gone for good)