If a given .desktop file has an Exec line like, say: Exec=test-app -i %f Which is perfectly legal in the .desktop spec, 'xdg-open <file>' will actually execute 'test-app <file>'. Attached is a patch that works. It should probably be looked at by something with a bit more shell scripting/sed finesse. It will also break if a filename has an asterisk in it -- it seemed the safest character to use as a sed delimiter.
Created attachment 39042 [details] [review] xdg open patch
Created attachment 39295 [details] [review] xdg-open patch Modified patch to work with %F (I think it'll still break with multiple files, but fixes some problems on my computer)
updating summary, to make it clear this only affects open_generic. I wonder why open_generic_xdg_mime is called *prior* to other potentially more reliable mechanisms like mimeopen.
My system (Arch Linux) doesn't have mimeopen installed -- I'm not sure where it comes from. Is this code deprecated, btw? I notice there hasn't been a release in years, but I'm not sure if that's just because it 'wasn't broken'. It's only since switching from XFCE to E17 for my DE that this became an issue, I guess since it actually starts falling back to the generic code. (In reply to comment #3) > updating summary, to make it clear this only affects open_generic. > > I wonder why open_generic_xdg_mime is called *prior* to other potentially more > reliable mechanisms like mimeopen.
mimeopen is a perl thing (perl-File-MimeInfo). These generic fallbacks are just that, last-resort things to try, when the native desktop doesn't provide facilities to do it already (like gnome and kde do). deprecated? no, I hope not! Though, not having a recent release is certainly not good (certainly counter to ... releaes early, release often). I've personally pushed for that, but I'm also not the one doing the work there (I could do more to help in that regard too... put up or shut up... kind of thing). :)
Yeah, I know how that goes. There are a lot of issues with freedesktop not using freedesktop stuff. For example, xdg uses the 'file' command to determine mime types, instead of using the freedesktop shared-mime-info package. Is it worth spending some time, you think, for me to make the generic fallbacks more robust? Or is it a freedesktop decision that the DE should always handle it? I would hate to spend time working on it and then it never gets released tho :) (In reply to comment #5) > mimeopen is a perl thing (perl-File-MimeInfo). > > These generic fallbacks are just that, last-resort things to try, when the > native desktop doesn't provide facilities to do it already (like gnome and kde > do). > > deprecated? no, I hope not! > > Though, not having a recent release is certainly not good (certainly counter to > ... releaes early, release often). I've personally pushed for that, but I'm > also not the one doing the work there (I could do more to help in that regard > too... put up or shut up... kind of thing). :)
> Is it worth spending some time, you think, for me to make the generic fallbacks > more robust? Yes please. (and/or we could try using other alternatives like gvfs-open or kde-open even when not on gnome or kde).
I ran into this bug too. Is there any reason not to apply the above patch?
Hrm, I cannot find a reproducible test-case test this bug and it's fix. Care to provide one? Seems no matter what I do, I always get: xdg-open: no method available for opening ...
OK, pebcak on my part, testing.
OK, after further testing, looks like open_generic_xdg_mime cannot properly handle .desktop vendor. :( I'll have to fix that too.
OK, I'm close but now the code you provided as-is seems to open files twice, I was hoping to avoid having to grok your regexp. :)
K, looks like we'll have to handle all of: %f %F %u %U (even though xdg-open only handles one file at a time currently) http://cgit.freedesktop.org/xdg/xdg-utils/commit/?id=a616912e48b7ff1d908852739d16525df79471b9
*** Bug 38047 has been marked as a duplicate of this bug. ***
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.