RFC: relative executables in desktop files

[David Faure]

On dimanche 10 mai 2020 19:17:01 CET Aleix Pol wrote:
> On Sun, Apr 26, 2020 at 1:36 PM David Faure <faure at kde.org> wrote:
> > 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?
> 
> One thing to note, which is probably easy to support: at the moment in
> kwin we're relying on certain apps to be defined in absolute paths for
> some security measures.
> 
> Just supporting $PATH makes most sense to me, there's increasingly
> other ways to distribute software that abstract XDG out (e.g. snap,
> appimage and flatpak). Weird custom uses should become increasingly
> more rare over time.

Hi Aleix,
There's some interest in reviving this discussion, about the usefulness of 
relative paths (for the Exec field of desktop files) even in the case of 
AppImages. See 
https://gitlab.freedesktop.org/xdg/xdg-specs/-/issues/71

I would be very interested in getting your feedback (you and anyone else of 
course) in that issue (not here please).

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