Without changing their extension:
As such, an appimage can be mounted or extracted. That is:
To mount them: (which amounts to executing them, something the OP wants to avoid - and for that very reason needs to be aware of - as stated in a comment by @Jasen)
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:
![enter image description here](https://cdn.statically.io/img/i.sstatic.net/br67J.png)
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
.)
mount
, but even that requires you to extract the image offset from the file. Creating an external command that can do the mounting automatically is filed as bug #830 in their bug tracker.