* xdg-open may or may not return immediately
For instance try:
echo Bar >foo.txt
In Gnome xdg-open returns immediately while in KDE / Mailcap it blocks until the application exits.
* xdg-open may or may not return an error when the association is missing
For instance try:
dd bs=1 count=20 if=/dev/random of=foo.noassoc
In Gnome / Mailcap it returns immediately with a non-zero exit code, while in KDE blocks while it opens a dialog asking what application to open the file with. If you click cancel in that dialog xdg-open exits with zero as the exit code.
These two properties make it very hard for a GUI application to know if the file was opened correctly or not as you cannot rely on its exit code. Not only could it very well be zero in the case of a missing association, but how long should one wait to obtain it?
for the first poing, under kde 4.3 i can't reproduce. As soon as the application is start xdg-open returns.
for the second this is how kde works so i don't think we can do anything.
Fabo, what do you think about this ?
Maybe the way to go is to get Gnome/KDE to add options to their respective tools so that it is possible to get a consistent behavior in xdg-open.
What's the status of this bug? Since from last comment have passed 8 months.
I have just checked and in gnome 2.30 the behavior is the same as explained in the bugreport. What about KDE?
That is, in gnome:
xdg-open foo.txt returns immediately with error code 0
xdg-open foo.noassoc returns immediately with error code 4
I retested on Fedora Core 12 which has KDE 4.4.2:
xdg-open foo.txt returns immediately with exit code 0.
xdg-open foo.noassoc blocks and pops up a dialog asking what one wants to do. When you click on Cancel you get an exit code of 0.
Based on the feedback here, seems we cant rely on the exit code of xdg-open's helper applications (kde-open in particular).
Though, it would appear, we should be using kde-open --noninteractive to avoid those potential popups.
*** Bug 36126 has been marked as a duplicate of this bug. ***
fyi, blocking on kde upstream bug
before implementing the use of kde-open --noninteractive
(In reply to comment #8)
> fyi, blocking on kde upstream bug
> before implementing the use of kde-open --noninteractive
The upstream bug is now RESOLVED FIXED.
A key benefit of using kde-open is KDE 4 compatibility: in kfmclient work-around code, xdg-open now calls kde-config which does not exist in KDE 4.
it calls kde4-config when/if kde is present
> it calls kde4-config when/if kde is present
In the latest stable release available from http://portland.freedesktop.org/download, xdg-utils 1.0.2, it calls kde-config.
both git and
are fixed to use kde4-config
> both git and
> are fixed to use kde4-config
Good to know.
What chance of upgrading to use the lighter-weight "kde-open --noninteractive" by the next stable release, now that the upstream bug has been fixed?
chances are good.
sorry for the delay, but better late than never.
Author: Rex Dieter <firstname.lastname@example.org>
Date: Mon Jun 30 07:54:50 2014 -0500
Revert "xdg-open: use 'kde-open --noninteractive' (BR16295)"
This reverts commit 869b22b75fc6e7c9e29ba5367bd97ebf7ce76cb3.
kde-open --noninteractive is still crashy :(
Should this bug be retitled to be specific to kde-open now?
(In reply to Reuben Thomas from comment #17)
> Should this bug be retitled to be specific to kde-open now?
This still impacts xdg-open so I think the title should remain as is. However it should link to the 'kde-open --noninteractive' bug.