GitHub - mgord9518/shappimage: An AppImage implementation made in shell script · GitHub
/" data-turbo-transient="true" />
Skip to content
Type / to search
Sign in<br>Sign upAppearance settings
You signed in with another tab or window. Reload to refresh your session.<br>You signed out in another tab or window. Reload to refresh your session.<br>You switched accounts on another tab or window. Reload to refresh your session.
Dismiss alert
{{ message }}
mgord9518
shappimage
Public
Notifications<br>You must be signed in to change notification settings
Fork
Star<br>16
main
BranchesTags
Go to file
CodeOpen more actions menu
Folders and files<br>NameNameLast commit message<br>Last commit date<br>Latest commit
History<br>89 Commits<br>89 Commits
.github/workflows
.github/workflows
resources
resources
LICENSE
LICENSE
README.md
README.md
add_integration.sh
add_integration.sh
make_runtime.sh
make_runtime.sh
runtime.sh
runtime.sh
View all files
Repository files navigation
shImg (shappimage)
A proof-of-concept implementation of AppImage created in shell script
How different is it from standard AppImage?
The ultimate goal is to have it be almost identical in normal use, but it isn't<br>quite there yet. It's currently missing the ability to extract without requiring<br>FUSE on the system, along with requiring fusermount3, which only exists on<br>FUSE3 systems. Assuming you're on a modern system with FUSE3 though, it should<br>work just like normal AppImages (assuming your file manager allows launching<br>scripts as applications instead of just opening them in an editor)
The shImg runtime has a longer initialization time compared to standard the<br>standard runtime. I've tried to optimize it a bit, but it still takes about<br>0.08s on my (fairly bad) hardware (mind you, Python 3 takes 0.1s on my system<br>just to initalize and make a print statement, so it probably won't hurt<br>performance that much for most things).
Another difference is the default compression being LZ4 (LZ4_HC) instead of LZIB,<br>I decided this because LZ4 compression is practically free while still getting<br>a decent (40%-60%) compression ratio. ZSTD is also supported as an option for<br>both mid and high compression at the cost of longer launch time, but it should<br>still be signifirantly faster than both ZLIB and XZ. Larger apps quickly reveal<br>the benefit of using decompression optimized for modern hardware. Using LZ4, I<br>generally get apps 30%-50% larger than ZLIB, but the return is a near-native<br>launch speed.
How does it work?
Overall it's pretty simple, the script checks if the user has squashfuse/dwarfs<br>binaries on their system (prefers this), if not it will extract a portable<br>binary to $XDG_RUNTIME_DIR. It then uses the binary to mount the attached<br>filesystem image at the specified offset, runs AppRun then unmounts and cleans<br>up once finished. See File structure for more info
Packaging an application
Eventually I would like to make a proper tool for building shImgs, but for the<br>time being, manually building is simple enough.
Assemble an AppDir
Compress the AppDir into a SquashFS image mksquashfs AppDir AppDir.sqfs -b1M -comp lz4 -Xhc
LZ4 should be used for applications where launch speed is preferred, ZSTD<br>should be used in applications where maximum compression is preferred.
Download or build the shImg runtime
Concatenate the runtime and filesystem image cat runtime-[COMPRESSION]-[ARCHITECTURES] AppDir.sqfs > app.shImg
At this point, the shImg should be a working application given that it's marked<br>executable or launched directly through the interpreter (eg: sh ./app.shImg)<br>but the desktop integration zip should also be<br>applied as it'll make it easier to integrate into the target system (once a<br>final structure is decided on and software is made to supoort it)
AppDir
An AppDir is composed of all<br>the files your application requires to run. It should be arranged in<br>FHS, although any file<br>layout works so long as your application is configured to load from relative<br>locations.
Applications MUST not use absolute paths for loading built-in resources
Applications should make as few assumptions about the base system as reasonably<br>possible. Static linking is preferable for maximum compatibility with systems<br>like Alpine and NixOS.
AppDirs in shImg may be extended to support multiple system architectures in<br>one image. To do so, you may either detect and run the appropriate binary<br>using your AppRun, or provide an AppRun.[ARCH] eg: AppRun.aarch64,<br>which the shImg runtime will prefer if the user is running said CPU.
File structure
The shell script (with the help of some attached fuse binaries) do the same<br>job as the standard AppImage type 2 runtime, simply trying to find the image<br>offset as fast as possible, mount it and run the contained application inside<br>the SquashFS bundle. The (possibly multiarch) payload is appended, which<br>contains the app itself.
Finally, a zip archive is slapped on the end to serve as desktop integration<br>information. Zip was chosen over other...