The .desktop files have become the de-facto standard to easily access applications on Linux desktops, with executables not being easily startable from the GUI otherwise and many launchers not using the app icon but only the icon specified in the .desktop file.

Why then, does it not seem possible to use .desktop files that specify a relative path to their executable and is there a way around this?

When shipping software that one does not want to force users to install, relative paths are the only way to enable this.

AppImage seems to work around this by installing a .desktop file when being run for the first time by the user, which seems like a kludgy way to enable icons and launchers for software with a flexible path. Relative paths would be a much better way to go. Why is this solution then not possible on Linux desktops? It seems unlikely that this is a mere oversight but that I am instead missing the deeper reason behind this decision.

  • There's been a (now deleted) answer, that I still want to address: the paths would be relative to the location of the .desktop file. So you'd have a directory containing all the relevant files for an application, somewhat similar to Mac OS's .app/ concept. Edit: answer back up, so I would've commented there then.
    – Christian
    Mar 8, 2018 at 10:50

5 Answers 5


You could use an inline shell script to compute the path:

Exec=sh -e -c "exec \\"\\$(dirname \\"\\$0\\")/some_app\\"" %k

Yes, two levels of escaping are required.

  • 1
    That's a nice solution to run the binary itself, but it does not really address the fact that .desktop files do inherently not seem suitable for "non-installed" applications. Case in point, since the Icon= field is still absolute, the application will show an ugly question mark in the launch bar and the .desktop file is shown with some broken/default icon in the file manager :/
    – Christian
    Mar 9, 2018 at 9:58
  • Didn't work for me. But the general idea did (apparently %k is the directory path already): Exec=sh -c 'exec "%k/my_app"' Iconless is suboptimal, but good enough in some contexts.
    – Alcaro
    Jan 20, 2019 at 8:24

For the Exec fileld I suppose that the reason is that it is not obvious what path should be used as base. For example you expect relativeness to *.desktop file location, but I expect relativness to the Path value. And this ambiguity could lead to mistakes. Additionally the Path isn't required field, so it becomes more complicated what should be happened when the Exec got relative path and the Path isn't defined. More convinient to not state of supporting relative paths at all and expect only absolute paths and binaries in the %PATH% directories.

For the Icon field treated in it's own way:

Icon to display in file manager, menus, etc. If the name is an absolute path, the given file will be used. If the name is not an absolute path, the algorithm described in the Icon Theme Specification will be used to locate the icon.

By the way, they (standards.freedesktop.org) no pronounce the supporting of the relative paths, but in fact seems like *.desktop files supports that.

If you write ./ before file name - it will run the executable in the Path folder.

[Desktop Entry]
  • this solution does not work, relative paths don't work in the .desktop files Jan 8, 2019 at 11:57
  • For me It works as I described (there is no formatting in comments as I see, so in one line): printf "#! /bin/sh\n\necho TheApp called, press any key to close\nread" > /tmp/TheAppExecutable.sh && chmod +x /tmp/TheAppExecutable.sh && printf "[Desktop Entry]\nName=TheApp\nType=Application\nTerminal=true\nPath=/tmp\nExec=./TheAppExecutable.sh" > ~/.local/share/applications/theapp.desktop
    – Ovsyanka
    Jan 9, 2019 at 12:24
  • And it is not 'solution', it is just observation. Because I wouldn't advise to use that. As I said in my answer there is no guarantee in documentation that it will be work in this way. Actually maybe it is not work on your system? Could you tell me does the application from my previous comment run on your system?
    – Ovsyanka
    Jan 9, 2019 at 12:38
  • How can I make the Path relative so that the Exec doesn't have to be? Aug 9, 2019 at 16:17

Keep in mind that the FreeDesktop standard is just that: a standard. In principle a vendor such as KDE, GNOME, LXDE, or XFCE could add support for relative paths without going through the standards process, but in practice none of them have. (I know for sure that neither GNOME 3.28.2 nor KDE Plasma 5.12.9 support relative paths, and to the best of my knowledge no other desktop environment does either.)

Why is this?

Reason 1: The simplest version of relative paths would conflict with the existing standard.

Consider this desktop file:

[Desktop Entry]
Name=My example app

The FreeDesktop specification says:

Standard Keys


Icon to display in file manager, menus, etc. If the name is an absolute path, the given file will be used. If the name is not an absolute path, the algorithm described in the Icon Theme Specification will be used to locate the icon.

[ . . . ]

Values of type iconstring are the names of icons; these may be absolute paths, or symbolic names for icons located using the algorithm described in the Icon Theme Specification. Such values are not user-displayable, and are encoded in UTF-8.

Since example-app is not an absolute path, menus and panels that want to display the icon will follow the icon theme specification to find the correct path, usually by looking in a folder like


However, example-app is also a valid relative path, so the icon string is now ambiguous. If one desktop environment adopts relative paths and the others don't, it would break compatibility.

Similarly, consider the Exec key:


According to the spec, it must be either a full path (i.e. absolute path) or an executable in $PATH:

The Exec key must contain a command line. A command line consists of an executable program optionally followed by one or more arguments. The executable program can either be specified with its full path or with the name of the executable only. If no full path is provided the executable is looked up in the $PATH environment variable used by the desktop environment.


So my_example_app should be looked up in $PATH, but if we consider this a relative path, we'll have to look somewhere that might not be in $PATH at all. Which one gets precedence?

Now, perhaps we could require all relative paths to be prefixed with ./ to disambiguate them. Since / is not allowed in filenames, this wouldn't be ambiguous, e.g.:


for a file in the same working directory or


for a file in the parent directory.

This brings up another question: what counts as the working directory?

Reason 2: The intended working directory for a desktop file may be unclear.

Desktop files can set the working directory with the Path key:


If entry is of type Application, the working directory to run the program in.

So if a desktop file had a valid Path key and were to specify a relative path like this:


would that be relative to the location of the desktop file or relative to the Path key?

There are other possibilities to consider.

  • Should the paths be relative to $XDG_DATA_HOME?

    This would make some sense since it's where the actual desktop files and icons are stored, but it's not where the executables are stored.

  • Should the paths be relative to the working directory of the launcher process?

    This would make sense since this process that shows the panels or menus is the one that needs to know where the executable and icon is. Usually the working directory of the window manager is the user's home directory, but in principle the working directory could be anywhere.

Reason 3: Relative paths must be updated if the desktop file is moved.

OK, let's suppose we specify that the paths to both the executables and icons are always relative to the desktop file, ignoring the Path key, the launcher process, and everything else.

Now suppose we want to copy that desktop file somewhere else, such as:


Now the relative path is different, and we'll have to edit the desktop file and change the path all over again. Using either absolute paths or standard folder locations solves this problem.

Reason 4: Menus and panels may require desktop files to be in arbitrary locations.

As long as we keep the desktop file in the same directory and only run it with the file manager, relative paths will work. But suppose we want to run our desktop file from a menu or panel launcher. Now the desktop file might be in


or it might be in


or in


and note that the relative path to an icon or executable is not the same for any of these. Moreover, depending on $XDG_DATA_HOME and $XDG_DATA_DIRS, the desktop file could be somewhere else entirely.

In the original question, the stated use-case is to run executables from the GUI and display custom icons without installing.

with executables not being easily startable from the GUI otherwise and many launchers not using the app icon but only the icon specified in the .desktop file.

Why then, does it not seem possible to use .desktop files that specify a relative path to their executable and is there a way around this?

When shipping software that one does not want to force users to install, relative paths are the only way to enable this.

One reason why we bother with a standard installation process for software in the first place is to place resources in a standard location so that other processes can find them. This makes installing and uninstalling more complicated, but helps with things like caching and debugging since there's fewer directories to check.

If we don't want to install the executable, we can still run it via a relative path, but if we want the convenience of launching it via another process (e.g. a menu launcher or panel), the other process has to know where to look, and since each process has its own working directory, their relative paths may be different.

The spec has this to say:

So, you're an application author, and want to install application icons so that they work in the KDE and Gnome menus. Minimally you should install a 48x48 icon in the hicolor theme. This means installing a PNG file in $prefix/share/icons/hicolor/48x48/apps. Optionally you can install icons in different sizes. For example, installing a svg icon in $prefix/share/icons/hicolor/scalable/apps means most desktops will have one icon that works for all sizes.

So we can install an icon here:


or here:


Then simply refer to the iconstring as example-app like this:


and the launcher process will be able to find the icon.

This is not really a relative path, but it solves the problem of having to use an absolute path, and it won't break if the desktop file is moved to a different location.

The same applies to the Exec key, except it's executables somewhere in $PATH instead of images in icon folders.

Epilogue: prior discussion and links.

It should be noted that support for relative paths to icons has been discussed on the FreeDesktop mailing list at least as early as September 2008:

Magnus Bergmark magnus.bergmark at gmail.com

Tue Sep 23 01:01:32 PDT 2008

[ . . . ]

I propose that we allow the usage of relative paths in some way also.


  1. I use a lot of .directory files to make directories containing a movie have the movie poster as the icon. This behaviour could apply to any form of media, like comic books, music (album art) and photos.

  2. A vendor might want to bundle an icon to a piece of software they're distributing to go with a .desktop file which are not to go in the desktop menu and therefore are still located in the application directory.


The only counterargument I was able to find to this proposal is here:

A .desktop file that is not intended to go into a standard applications directory is almost entirely useless. Perhaps you should look at some of the software bundle proposals and implementations, and work with using those, instead. Another option is the xdg utils scripts, to install the .desktop file and icons in the appropriate places. I can only presume that your uninstalled application also intends to not follow the Icon Theme and Icon Naming specifications either. And I don't see setting the directory's icon as useful really. Setting an icon for the actual executable would be much more useful, though elf binaries do not have resources like win32 binaries do.


Related questions:

Relevant links:

  • The relativity is the root folder and thee question was how to move the realativity to some thing that does not break your machine. IT does matter what you want or any body else its slavish, let the man change his relativity for crying out loud, its cripplware
    – abc
    Oct 15, 2020 at 2:33

I needed a path relative to the home directory in my firefox.desktop. Such that every user get's his own firefox-profile started, i.e. firefox-frank sitting in ~/Documents/... aka /home/frank/Documents/...

And this is the Exec-line, that works: (thanks to @timothy-baldwin answer above)

Exec=sh -e -c "/usr/bin/firefox -profile \"/home/$(whoami)/Documents/chrome-profiles/firefox-$(whoami)\""

In order to appreciate the situation, ask yourself, "Relative to what?". The .desktop files are for use within GUI contexts, for which no base path can be assumed upon which to build an absolute path from any relative path you might consider putting in the .desktop file.

Relative paths are only useful when they can be converted to a definite location (the absolute path), and that requires a reference point. which can't be assumed in any generic GUI context.

  • Since your answer disappeared for me briefly, I reacted to it in a comment to the question.
    – Christian
    Mar 8, 2018 at 10:51
  • 4
    Relative to the literal path of the .desktop file, for system managed desktop files where this isn't already needed, it doesn't need to be used... Aug 9, 2019 at 16:15
  • It is relative to root folder. Attacking relativity is crazy. Let the man change the realativity to his own user account you windy crippleware CNT
    – abc
    Oct 15, 2020 at 2:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.