From the AppImageKit README:
Special directories
Normally the application contained inside an AppImage will store its
configuration files wherever it normally stores them (most frequently
somewhere inside $HOME
). If you invoke an AppImage built with a
recent version of AppImageKit and have one of these special
directories in place, then the configuration files will be stored
alongside the AppImage. This can be useful for portable use cases,
e.g., carrying an AppImage on a USB stick, along with its data.
- If there is a directory with the same name as the AppImage plus
.home
, then $HOME
will automatically be set to it before executing
the payload application
- If there is a directory with the same name as the AppImage plus
.config
, then $XDG_CONFIG_HOME
will automatically be set to it
before executing the payload application
Without changing their extension:
As such, an appimage can be mounted or extracted. That is:
To mount them:
my.AppImage --appimage-mount
The AppImage is unmounted when the application called in the example
is interrupted (e.g., by pressing Ctrl+C, closing the terminal etc.).
Note: This is only available for type 2 AppImages. Type 1 AppImages do
not provide any self-mounting mechanism. To mount type 1 AppImages,
use
mount -o loop
To extract them:
An alternative to mounting the AppImages is to extract their contents.
This allows for modifying the contents. The resulting directory is a
valid AppDir, and users can create AppImages from them again using
appimagetool
.
Analog to mounting AppImages, there is a simple commandline switch to
extract the contents of type 2 AppImages without external tools. Just
call the AppImage with the parameter --appimage-extract
. This will
cause the runtime to create a new directory called squashfs-root
,
containing the contents of the AppImage’s AppDir specification.
Type 1 AppImages require the deprecated tool AppImageExtract
to
extract the contents of an AppImage. It’s very limited functionality
wise, and requires a GUI to run. It creates a new directory in the
user’s desktop directory.
There is an answer on superuser on how to extract files from an AppImage.
Looking at my appimages I see that only some of them can be mounted with gnome-disk-image-mounter. Also here.
Changing their extension:
Not all appimages have exactly the same structure, but all are archives. Wikipedia says: "An AppImage of version 1.0 is an ISO 9660 Rock Ridge file (which can be optionally zisofs compressed) containing a minimal AppDir and a tiny runtime. (Version 2 may use other file system image formats like SquashFS)".
So, it can be extracted. In this way you can examine the files.
Simply changing the extension from AppImage
to an archive extension that my file-roller archive manager can read (I tested with zip
, 7z
, etc) and double-clicking the file reveals the contents in file-roller:
They can also be extracted, of course. The "extract" file manager context menu action works too in order to extract the archive. (As said in comment, the unzip
command reports an error with a file renamed with a zip
extension, so renaming to zip
is not the proper choice in itself, but it works with archive managers like file-roller
.)
Best Answer
Basic Information
Regarding installation
I am quoting the appImage project page here:
Making it executable
You can make the appImage executable as follows:
Executing it
You can execute an appImage as follows:
Additional Information
About appImage
You can find some general informations about appImage here.
I am quoting the appImage project page here:
Wikipedia adds
The
README.md
of the AppImageKit-project offers a lot additional informations like Use cases, the problem space and objectives.Use Cases
As a user, I want to go to an upstream download page, download an application from the original author, and run it on my Linux desktop system just like I would do with a Windows or Mac application.
As a tester, I want to be able to get the latest bleeding-edge version of an application from a continuous build server and test it on my system, without needing to compile and without having to worry that I might mess up my system.
As an application author or ISV, I want to provide packages for Linux desktop systems just as I do for Windows and OS X, without the need to get it 'into' a distribution and without having to build for gazillions of different distributions.
Objectives
Be Simple.
Maintain binary compatibility.
Be distribution-agnostic.
Remove the need for installation.
Keep apps compressed all the time.
Allow to put apps anywhere.
Make applications read-only.
Do not require recompilation.
Keep base operating system untouched.
Do not require root.