RFC: relative executables in desktop files

David Faure faure at kde.org
Sun Apr 26 12:36:32 BST 2020


During the review of https://phabricator.kde.org/D29170 the following question surfaced again: should it be possible for a desktop file to refer to an executable that is in the "current directory", for some definition of that term. At least, outside of $PATH.

In my opinion, in a GUI program started graphically, the notion of "current dir" (QDir::currentPath()) has no meaning. The user can't see it and can't change it. When starting the program from the command line it does serve a purpose for command line arguments, but IMHO not after that (e.g. if you navigate to another dir in dolphin, QDir::currentPath() still points to the directory you started dolphin from).

There is however another "current directory" that might make more sense when starting a desktop file: the directory of the desktop file itself.

There are actual use cases for that, see this very old request on the XDG mailing-list: 
https://lists.freedesktop.org/archives/xdg/2011-April/011883.html

AFAICS this discussion has 3 possible outcomes:

* We do not support starting executables that are not in $PATH, end of story.
That was actually what I had in mind when writing the code initially, any use of API that also looked in the current directory (like QFileInfo::exists) was accidental. Unless I'm mistaken, this is how it's been until now. It's also what the XDG spec [1] says.

* We support launching executables relative to the desktop file, transparently. In the same directory, put a copy of dolphin called dolphin2, and a copy of org.kde.dolphin.desktop modified to say Exec=dolphin2, and clicking on the desktop file starts dolphin2. That's what my current revision of D29170 does.
I'm wondering if this is the right thing to do though.
After all, on the command line "foo" doesn't start a local executable called foo, only ./foo does that. Except for people who add "." to $PATH, but that's generally not recommended (security, accidental use of wrong binary).

* We could also adopt the above proposal from the xdg list, which is that Exec=foo only looks in $PATH, while Exec=./foo only looks in the directory of the desktop file.

(I'm purposefully excluding the 4th option, resolving relative to QDir::currentPath() which as explained at the top, would be nonsense IMHO)

Thoughts?

[1] https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html#exec-variables

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5





More information about the Kde-frameworks-devel mailing list