relative paths in Exec= in .desktop and .service files

[Simon McVittie]

On 08/09/14 13:23, Simon McVittie wrote:
> 3) contains a path separator but is relative
> 
> This is not currently in either specification: it is unspecified what
> Exec=../bin/foo or Exec=./foo would do.
> 
> Reasonable possibilities include:
> 
> * it's relative to the directory containing the executable that is
>   interpreting the file, e.g. dbus-daemon[.exe], i.e. normally /usr/bin

I think this is probably the most useful set of semantics for
relocatable applications.

One additional open question here: if the executable is a symlink, is
the path relative to the location where it was found, or the "real path"?

> * it's relative to the getcwd() of the process that is interpreting
>   the file, i.e. normally / or $HOME

This is awkward for relocatable applications, since the current working
directory is not particularly predictable; it can be worked around by
making the process that is interpreting the file (e.g. gnome-session or
dbus-daemon) chdir() into a known location, such as the directory
containing its executable, but then that chdir() becomes de facto API.

> * it's relative to the directory containing the file itself,
>   i.e. normally /usr/share/applications

This is more annoying for relocation because ${prefix} and
${exec_prefix} might differ, but it's easy to explain (and consistent
with, e.g., HTML links).

The same question about symlinks applies.

    S