a portable application should be portable no? this means not leaving traces in $home, %appdata, etc. deployable from a network share, usb fs, anywhere, but generating many likely conflicts from for example ~/.links2 across my network. I love what yall are driving at here but until I can see some method of like installing to a USB disk and keeping libraries [which works thus farly] AS WELL as configuration uhhh like vmwares thinapp system. Portableapps platform is another good one, again, only on windows… then again one can just write a batch script giving environmental prams set appdata=%CD%\data on some things.
dephell is never a fun place to be, i dont know where to post this but try and hear me 
you all rock
1 Like
AppImages are “portable” in the sense that you can copy the one app = one file to a different system and it should run.
They are not portable in the sense that data (such as created documents and/or settings, caches) travels with them.
But on Linux, this is quite easy to achieve:
Simply launch it like this: export HOME=/where/you/want/your/data ./some.AppImage. You can even put something like this into a script.
If have been considering to make the following feature: If there is a directory with the same name as the AppDir and a special suffix present next to the AppImage location, then use that as the $HOME for the AppImage. Would you be interested in such a functionality?
1 Like
oh that is exactly what im looking for, ive already been using the bash function export HOME on several other scripts
brilliant!
Similar discussion: https://github.com/AppImage/AppImageSpec/issues/4
I though the same thing and that’s why I created LinuxPA. If you go into setting and enable common.sh it will run before the program, so you can set things such as HOME (which the default common.sh does).
https://github.com/AppImage/AppImageKit/commit/d17fdefadcb98befa66c29137ce25731256f8f2a implements the following:
- If there is a directory with the same name as the AppImage plus
.home, then export$HOME. - If there is a directory with the same name as the AppImage plus
.config, then export$XDG_CONFIG_HOME.
All new AppImages generated with the latest continuous build of appimagetool will have this functionality.
Depending on how well this works in practice, it may become part of the spec.
Example on how to use this.
Imagine you want to use the Leafpad text editor, but carry its settings around with the executable.
You can do the following:
# Download Leafpad AppImage and make it executable
wget -c "https://bintray.com/probono/AppImages/download_file?file_path=Leafpad-0.8.18.1.glibc2.4-x86_64.AppImage" -O Leafpad-0.8.18.1.glibc2.4-x86_64.AppImage
chmod a+x Leafpad-0.8.18.1.glibc2.4-x86_64.AppImage
# Create a directory with the same name as the AppImage plus the ".config" extension
# in the same directory as the AppImage
mkdir Leafpad-0.8.18.1.glibc2.4-x86_64.AppImage.config
# Run Leafpad, change some setting (e.g., change the default font size)
# then close Leafpad
./Leafpad-0.8.18.1.glibc2.4-x86_64.AppImage
# Now, check where the settings were written:
linux@linux:~> find Leafpad-0.8.18.1.glibc2.4-x86_64.AppImage.config
(...)
Leafpad-0.8.18.1.glibc2.4-x86_64.AppImage.config/leafpad/leafpadrc
Note that the file leafpadrc was written in the directory we have created before.
Hello probono,
i have follow the same step for firefox appimage.
Created Firefox-54.0.glibc2.3.4-x86_64.AppImage.config directory for Firefox-54.0.glibc2.3.4-x86_64.AppImage .
Make changes to settings in the firefox.
close it.
i don’t see any new data been saved in Firefox-54.0.glibc2.3.4-x86_64.AppImage.config directory .
please enlighten me on where are the data been saved to?
How do i make sure my data are store along with appimage in the same directory?
This AppImage does not have this functionality yet. It was introduced in a later version of AppImageKit.
First quit all currently running instances of Firefox:
killall firefox
Then download the AppImage from https://bintray.com/probono/AppImages/Firefox/56.0.2.glibc2.3.4#files
mkdir Firefox-56.0.2.glibc2.3.4-x86_64.AppImage.home
./Firefox-56.0.2.glibc2.3.4-x86_64.AppImage
After running the AppImage, you can inspect the contents of Firefox-56.0.2.glibc2.3.4-x86_64.AppImage.home and you will see stuff has been saved there:
me@host:~/Downloads$ find Firefox-56.0.2.glibc2.3.4-x86_64.AppImage.home/ | head -n 10
Firefox-56.0.2.glibc2.3.4-x86_64.AppImage.home/
Firefox-56.0.2.glibc2.3.4-x86_64.AppImage.home/Desktop
Firefox-56.0.2.glibc2.3.4-x86_64.AppImage.home/.cache
Firefox-56.0.2.glibc2.3.4-x86_64.AppImage.home/.cache/fontconfig
(...)
Firefox-56.0.2.glibc2.3.4-x86_64.AppImage.home/.cache/fontconfig/CACHEDIR.TAG
Firefox-56.0.2.glibc2.3.4-x86_64.AppImage.home/.cache/mozilla
(...)See this asciicinema for a live demo:
probono: ok
thank you.
This use case should be shown in the README.md in GitHub.
Moreover, have you thought about extending this approach?
Think of the following use case, we have a software which supports Plug In’s.
It expects the Plug In’s to be in a certain location which is not ~/ related.
So could we have something like AppData folder next to the AppImage which can be configured to be copied to somewhere to allow Plug In’s functionality?
Really like the Portable Data Feature.
I think this is your edge over FlatPak and Snap (Allowing Portable Use Case).
All needed now it Portable AppImage which is a Menu System to launch other AppImages (Think like the PortableApps Menu which is a portable application by itself, no system wide installation).
Added.
This is probably something specific to the application in question that should best be implemented either within the application itself, or by writing a custom AppRun launcher. Every application probably needs some environment variable to be set in order to load plugins from custom locations. Actually I would assume that most will (also) load plugins from somewhere within $HOME, so the .home feature (described above) that is already available might be sufficient in many cases.
@probono,
Do you expect that TeXStudio will download MiKTeX to .home?
Let’s sya I use both TeXMaker and TeXStudio, should I expect each to download MiKTeX?
There should be a well defined way to have AppImage format auxiliary data.
Again, have a look on PortableApss approach for that.
No, if TeXStudio requires MiKTeX to work properly, then I expect a TeXStudio.AppImage to contain MiKTeX. Because an AppImage is supposed to run without the user needing to download anything else besides the AppImage.
But in most cases Minimal TeXLive won’t cut it.
So you suggest user who use both TeXMaker and TeXStudio and needs extra packages to have 2 ~4 GB programs.
Yea, great user experience.
Not to mention the chances the TeXMaker / TeXStudio maintainers to have such a mess as a choice.
Really, those design choices only makes FlatPak / Snap look much more reasonable.
Flatpak and Snap allow dependencies. We discourage them. But hey, in the end it’s up to whoever makes the TeXMaker/TeXStudio AppImage to decide what goes inside and what doesn’t. Unlike Flatpak and Snap we don’t enforce things. We just provide the tools. AppImage does not restrict them from doing what they want to do. The developer of an AppImage can do what they want. An AppImage is just a self-mounting filesystem image (“disk image”) that runs what someone puts inside.
I tried the suggested solution to save appimage application settings in the same folder, by creating folder with the same name and extension .config or .home, but none of them worked. The folders are empty.
I also tried to change the home directory of appimage application by launching it with the command export HOME=/path/to/data/folder ./xxxx.appimage but also it didn’t worked. I get bash export not a valid identifier.
Hi @emil_9822, which AppImage? Try running the AppImage with --appimage-portable-home .
For more information, please see https://github.com/AppImage/AppImageKit/issues/539.
Please open an issue in https://github.com/AppImage/AppImageKit/ if it does not work with any AppImage.