Skip to content
Permalink
Branch: master
Find file Copy path
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
73 lines (54 sloc) 5.17 KB

Environment variables

The AppImage runtimes make some environment variables available that can be used by applications bundled as AppImages during runtime, e.g., to recognize whether it's currently run from an AppImage, or to get some path information.

Depending on the type of the AppImage, the runtimes offer different feature sets.

Type 1 AppImage runtime

Note

Type 1 is the deprecated/outdated AppImage type that is only in legacy support mode. It is not recommended to make new type 1 AppImages. We strongly recommend you to use appimagetool to make type 2 AppImages.

Variable name Contents
APPIMAGE (Absolute) path to AppImage file (with symlinks resolved)
APPDIR Path of mountpoint of the SquashFS image contained in the AppImage
OWD Path to working directory at the time the AppImage is called

Type 2 AppImage runtime

The type 2 AppImage runtime makes a few environment variables available for use in e.g., AppRun scripts:

Variable name Contents
APPIMAGE (Absolute) path to AppImage file (with symlinks resolved)
APPDIR Path of mountpoint of the SquashFS image contained in the AppImage
ARGV0 Name/path used to execute the script. This corresponds to the value you'd normally receive via the argv argument passed to your main method. Usually contains the filename or path to the AppImage, relative to the current working directory.

Note

APPIMAGE and ARGV0 have very different use cases.

APPIMAGE shall be used every time the full path of the AppImage is needed, e.g., if you need to touch the AppImage file, for example when you want to update it or read some meta information.

ARGV0 provides information how the AppImage was called. When you call an AppImage through a symlink for instance, you can get the path to this symlink through ARGV0, while APPIMAGE would contain the absolute path to the file behind that symlink.

Scenarios where ARGV0 is really useful involve so-called multi-binary AppImages, where the filename in ARGV0 defines which program is called inside the AppImage. This concept is also known from single-binary tools like BusyBox, and can be implemented in a custom AppRun script (see :ref:`Architecture <ref-architecture>` for more information).

You can’t perform that action at this time.