AppImage portable mode no longer works in Tumbleweed

Hi.

AppImages have a portable mode that allows for bundling an application’s data next to the application’s AppImage. In summary, how it works is 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. More information about this feature can be found from the official source here (Using portable mode — AppImage documentation)

I tested out 3 AppImages from there original source. The programs all function properly, just that the portable .home directory is not respected and application files are not placed within it.

Example of running GIMP AppImage:

Permissions:

example@example:~/test> ls -l 
total 161256 
drwxr-xr-x. 1 example user         0 Dec 13 00:00 GIMP-3.0.6-x86_64.appimage.home 
-rwxr-xr-x. 1 example user 165124600 Dec 13 00:00 GIMP-3.0.6-x86_64.appimage

Shell output:

example@example:~/test> ./GIMP-3.0.6-x86_64.appimage 
Setting $HOME to /home/example/test/GIMP-3.0.6-x86_64.appimage.home 
Gtk-Message: 00:00:00.449: Failed to load module "colorreload-gtk-module" 
Gtk-Message: 00:00:00.450: Failed to load module "window-decorations-gtk-module" 
set device 'Wayland Pointer' to mode: disabled

No program files actually get placed within /home/example/test/GIMP-3.0.6-x86_64.appimage.home as shown in the output above. Instead, they are placed in:

~/.cache/gimp
~/.config/GIMP
~/.local

My assumptions were that this could be a permissions or fuse issue, but I am not skilled enough using strace and not sure how to troubleshoot further.

Thank you.

Correct. AppImage isn’t actually portable, and many appimages expect certain things to exist on the host. And many of them make no mention of that fact.

I don’t do gtk much, so you’d need to figure out which openSUSE rpms provide ‘colorreload-gtk-module’ and ‘window-decorations-gtk-module’

Thanks for the reply. I understand that not all AppImages are portable in the sense of bundled libraries. This is not an issue about an AppImage not being portable in the sense that you run it on any distro with no compatibility issues. By portability, I am referring to the end user data that gets created using an AppImage, like app configs, cache, and user data.

All the AppImages tested work fine, it is the AppImage portable mode that allows for bundling an application’s data next to the application’s AppImage that isn’t working on Tumbleweed. The portable mode, is simply making directory with the same name as the AppImage plus .home, then $HOME will automatically be set to it before executing the payload application. For example, if you have an AppImage named “MelonDS.AppImage” and make a directory called “MelonDS.AppImage.home”, the application configuration, cache and user data would be stored in “MelonDS.AppImage.home” instead of the actual end user’s home directory.

The GTK-Messages you see are not relevant to the issue at hand. The relevant line was:

Setting $HOME to /home/example/test/GIMP-3.0.6-x86_64.appimage.home 

All AppImages that I have tested seem to be affected. They don’t place their application cache or config files in appimage.home but instead in the actual user’s home directory (~).

This used to work in Tumbleweed, then stopped. I am not sure which update or when it stopped. Though this feature still works on other distros such as latest Fedora and Debian.

Example of running MelonDS AppImage, the app runs fine, but where user data is placed is not:

Permissions:

example@example:~/test2> ls -l 
total 34056 
drwxr-xr-x. 1 example user         0 Dec 13 00:00 melonDS-x86_64.AppImage.home 
-rwxr-xr-x. 1 example user 34871800 Dec 13 00:00 melonDS-x86_64.AppImage

Shell output:

example@example:~/test2> ./melonDS-x86_64.AppImage
Setting $HOME to /home/example/test2/melonDS-x86_64.AppImage.home
melonDS 1.1

No application cache or config data files actually get placed within /home/example/test/melonDS-x86_64.AppImage.home as shown in the output above. Instead, they are placed in:

~/.config/melonDS

I hope this clarifies the issue.

1 Like

Interestingly, setting .config to be portable by doing the following works fine:

  • 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

It is just setting .home to be portable that does not work on Tumblweed.

  • 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

User Guide and Examples:
https://docs.appimage.org/user-guide/portable-mode.html

1 Like

As a test, I downloaded the latest release (as of this message) for multiple distros to test their behaviors. I kept the defaults throughout each respective installer when setting up on bare metal.

For the test, I placed GIMP.AppImage in the Documents directory and created the directory GIMP.AppImage.home beside the AppImage. This is all that is needed to make the application user data portable.

I launched the AppImage to see if the application user data was placed within ~/Documents/GIMP.AppImage.home. If the AppImage portable home is not respected, new folders end up being created, and the application user data ends up at ~/.cache/gimp, ~/.config/GIMP, and ~/.local/share.

What the hierarchy looks like:

📁 Root
└── 📁Home
       └── 📁.cache
       └── 📁.config
       └── 📁.local
       ├── 📁Documents
             ├── 📄GIMP.AppImage
             └── 📁GIMP.AppImage.home

Test results:

  1. CachyOS Desktop - Works, app user data within GIMP.AppImage.home
  2. Debian Stable - Works, app user data within GIMP.AppImage.home
  3. Fedora Kinoite Rawhide - Works, app user data within GIMP.AppImage.home
  4. openSUSE Leap 16 - Works, app user data within GIMP.AppImage.home
  5. openSUSE Tumblweed - Broken, app user data ends up at ~/.cache/gimp, ~/.config/GIMP, and ~/.local/share.

Not sure how to troubleshoot further, but the behavior seems to not occur in other distros. Seems the issue is not the AppImages but something about Tumblweed that changed. It used to work, just not sure what snapshot changed it.

1 Like

Good debug and interesting finding.

The portable mode logic doing this seems reasonably simple:

Do you see for the other distros see the output for this printf

fprintf(stderr, "Setting $HOME to %s\n", portable_home_dir);

One way to debug this is comparing a strace log between Tumbleweed and one of the other distros.

Thanks for the reply.

Yes, if you are referring to just the standard output when running the AppImage through the shell.

For example, Debian Stable output below:

example@debian:/home/test$ ./GIMP-3.0.6-aarch64.AppImage
Setting $HOME to /home/test/GIMP-3.0.6-aarch64.AppImage.home

The AppImage proceeds to launch and its user data files are placed in /home/test/GIMP-3.0.6-aarch64.AppImage.home.

All the distros I tested show this output/message, just Tumbleweed does not actually respect it. Maybe it actually tries to but fails silently due to an unknown reason.

Okay, can you the command you start the AppImage “under” strace:

strace --trace=file --output=tumbleweed.log <command to start AppImage>

And share then the lines in tumbleweed.log that accessing home files/dirs or share the complete log file, you can use https://paste.opensuse.org/ for that.

Full log:
https://privatebin.net/?223d2b0b46b77701#J6aWYAMC7iMz1PpBahRbVn2AxzHCZUMNXeyUJLdZUswo

What is interesting to me is this at the start, which means it does not have write access to the folder:
access("/home/example/Documents/GIMP.AppImage.home", W_OK) = 0

Here were the permissions during the test:

example@example:~/Documents> ls -l
total 165952
drwxr-xr-x. 1 example example         0 Dec 15 17:26 GIMP.AppImage.home
-rwxr-xr-x. 1 example example 165124600 Dec 15 17:25 GIMP.AppImage
-rw-r--r--. 1 example example   4806559 Dec 15 17:28 tumbleweed.log

Even if I set GIMP.AppImage.home to 777, still nothing gets written within it

1 Like

Sorry read a bit more, = 0, means access("/home/example/Documents/GIMP.AppImage.home", W_OK) = 0 has access. = -1, means no access.

I agree with your analysis, the strace access for .home seems to indicate access is fine:

access("/home/example/Documents/GIMP.AppImage.home", W_OK) = 0
access("/home/example/Documents/GIMP.AppImage.config", W_OK) = -1 ENOENT (No such file or directory)

I did just try the melon AppImage and created a dir:

mkdir Development/AppImage/melonDS-x86_64.AppImage.home

Then did run it and see:

strace --trace=file --output=/tmp/ramdisk/access.log ./melonDS-x86_64.AppImage
Setting $HOME to Development/AppImage/melonDS-x86_64.AppImage.home
melonDS 1.1
...
> grep 'melonDS-x86_64.AppImage' /tmp/ramdisk/access.log
execve("./melonDS-x86_64.AppImage", ["./melonDS-x86_64.AppImage"], 0x7ffd0032b700 /* 120 vars */) = 0
access("Development/AppImage/melonDS-x86_64.AppImage.home", W_OK) = 0
access("Development/AppImage/melonDS-x86_64.AppImage.config", W_OK) = -1 ENOENT (No such file or directory)
execve("/tmp/.mount_melonDPgmAgB/AppRun", ["./melonDS-x86_64.AppImage"], 0x25834040000 /* 124 vars */) = 0

So for my Tumbleweed system I see the “Setting $HOME” message and it seems to be working as expected.
Can you double check things?

No, does not work. I see the same setting home message and all looks valid.

If it truly worked, within your melonDS-x86_64.AppImage.home, you would see these folders:
melonDS-x86_64.AppImage.home\.cache\mesa_shader_cache
melonDS-x86_64.AppImage.home\.cache\mesa_shader_cache_db
melonDS-x86_64.AppImage.home\.config\pulse
If you look at your setup, you wont see the folders above and you will also see a folder is created at home/yourusername/.config/melonDS.toml that is where the emu config files are place. That means the. melonDS-x86_64.AppImage.home folder is not respected.

Did you give GIMP a try? If it does not work, you will get files at:
home/yourusername/.cache/babl
home/yourusername/.cache/fontconfig
home/yourusername/.cache/gegl-.04
home/yourusername/.cache/gimp
home/yourusername/.config/GIMP

If it does, these folders would be created within /GIMP.AppImage.home.

Happy to try out any AppImage. I just chose 3 random ones but any exhibit the issue on my end.

For me the App is opening:

But I do not have ROM’s so that is it. I a parallel session I did check the melonDS-x86_64.AppImage.home/ directory but is it empty. Also checked /tmp and also there I see no new directory created so is that only done once a ROM is loaded? I see the ~/.config/melonDS/melonDS.toml file.

No, I think that means that there is no melonDS-x86_64.AppImage.config directory and that is the case.

I did try gimp:

> md5sum GIMP-3.0.6-x86_64.appimage
2105536bdcc72e39abbfb6dbbdedf25e  GIMP-3.0.6-x86_64.appimage
> mkdir GIMP-3.0.6-x86_64.appimage.home
> mkdir GIMP-3.0.6-x86_64.appimage.config
> ./GIMP-3.0.6-x86_64.appimage 
Setting $HOME to ~/Development/AppImage/GIMP-3.0.6-x86_64.appimage.home
Setting $XDG_CONFIG_HOME to ~/Development/AppImage/GIMP-3.0.6-x86_64.appimage.config

On a parallel session:
> ll GIMP-3.0.6-x86_64.appimage.home
total 0
> ll GIMP-3.0.6-x86_64.appimage.config
total 0
drwxr-xr-x 3 marel marel 17 Dec 16 21:54 GIMP
drwx------ 2 marel marel  6 Dec 16 21:55 gtk-3.0

So both melon and gimp do not seem to use HOME but at least for gimp config is working.

1 Like

Appreciate you testing.

For melonDS, the app is functional here as well. It was wonky and a poor example, on my part. You have to make the a new melonDS folder at melonDS.Appimage.home/.config/ yourself. Once you do that, the .toml file will be created save there melonDS.Appimage.home/.config/melonDS.toml/

This is my fault for choosing it as an example as it is relatively new. Still, if it worked, you would have these folders populate within the melonDS.AppImage.home folder.
melonDS-x86_64.AppImage.home\.cache\mesa_shader_cache
melonDS-x86_64.AppImage.home\.cache\mesa_shader_cache_db
melonDS-x86_64.AppImage.home\.config\pulse

The issue is all these apps respect generic.Appimage.home and generic.Appimage.config on other distros. On Tumbleweed, only generic.Appimage.config is respected.

You are not supposed to have AppImage.home and AppImage.config at the same directory. If you use AppImage.home, it creates a .config folder within it.

In your example for testing GIMP, if you remove the GIMP.Appimage.config folder and just have GIMP.Appimage.home that should just work. It does not though, what will happen is it will place folders here:
home/yourusername/.cache/babl
home/yourusername/.cache/fontconfig
home/yourusername/.cache/gegl-.04
home/yourusername/.cache/gimp
home/yourusername/.config/GIMP

Tree -a example of after running GIMP.AppImage and having GIMP.AppImage.home in the same directory on Debian Stable:

example@debian:~$ tree -a Documents/
Documents/
├── GIMP.AppImage
└── GIMP.AppImage.home
    ├── .cache
    │   ├── babl
    │   ├── fontconfig
    │   │   ├── 0bd3dc0958fa2205aaaa8ebb13e2872b-le64.cache-9
    │   │   ├── 188ac73a183f12857f63bb60a4a6d603-le64.cache-9
    │   │   ├── 2300eef321c393bfd76478a5c0e95b23-le64.cache-9
    │   │   ├── 32b6488e5b8292a2e95c79d947e009e8-le64.cache-9
    │   │   ├── 3830d5c3ddfd5cd38a049b759396e72e-le64.cache-9
    │   │   ├── 4c599c202bc5c08e2d34565a40eac3b2-le64.cache-9
    │   │   ├── 573ec803664ed168555e0e8b6d0f0c7f-le64.cache-9
    │   │   ├── 57e423e26b20ab21d0f2f29c145174c3-le64.cache-9
    │   │   ├── 62f91419b9ebdb6975e7e41ab6412357-le64.cache-9
    │   │   ├── 6333f38776742d18e214673cd2c24e34-le64.cache-9
    │   │   ├── 6cc790b63b123a6a96ee260fcdad32a9-le64.cache-9
    │   │   ├── 707971e003b4ae6c8121c3a920e507f5-le64.cache-9
    │   │   ├── 7ef2298fde41cc6eeb7af42e48b7d293-le64.cache-9
    │   │   ├── 95530828ff6c81d309f8258d8d02a23e-le64.cache-9
    │   │   ├── 9b89f8e3dae116d678bbf48e5f21f69b-le64.cache-9
    │   │   ├── a4e60e8d1e10d2fdff3fe3037a1845fb-le64.cache-9
    │   │   ├── c3bb64600bf7a4aa73b55dc8bb82b27b-le64.cache-9
    │   │   ├── c855463f699352c367813e37f3f70ea7-le64.cache-9
    │   │   ├── cabbd14511b9e8a55e92af97fb3a0461-le64.cache-9
    │   │   ├── CACHEDIR.TAG
    │   │   ├── d3e5c4ee2ceb1fc347f91d4cefc53bc0-le64.cache-9
    │   │   ├── d589a48862398ed80a3d6066f4f56f4c-le64.cache-9
    │   │   ├── d82eb4fd963d448e2fcb7d7b793b5df3-le64.cache-9
    │   │   ├── e13b20fdb08344e0e664864cc2ede53d-le64.cache-9
    │   │   ├── e52a45a1c8c8fe895fc0fc8c4e6999b8-le64.cache-9
    │   │   ├── f1f2465696798768e9653f19e17ccdc8-le64.cache-9
    │   │   └── fe547fea3a41b43a38975d292a2b19c7-le64.cache-9
    │   ├── gegl-0.4
    │   │   └── swap
    │   └── gimp
    │       └── 3.0
    ├── .config
    │   └── GIMP
    │       └── 3.0
    │           ├── action-history
    │           ├── backups
    │           ├── brushes
    │           ├── colorrc
    │           ├── contextrc
    │           ├── controllerrc
    │           ├── CrashLog
    │           ├── curves
    │           ├── devicerc
    │           ├── dockrc
    │           ├── dynamics
    │           ├── environ
    │           ├── extensionrc
    │           ├── filters
    │           ├── fonts
    │           ├── fractalexplorer
    │           ├── gfig
    │           ├── gflare
    │           ├── gimpressionist
    │           ├── gradients
    │           ├── icons
    │           ├── internal-data
    │           │   └── custom.ggr
    │           ├── interpreters
    │           ├── levels
    │           ├── modifiersrc
    │           ├── modules
    │           ├── palettes
    │           ├── parasiterc
    │           ├── patterns
    │           ├── pluginrc
    │           ├── plug-ins
    │           ├── scripts
    │           ├── sessionrc
    │           ├── shortcutsrc
    │           ├── tags.xml
    │           ├── templaterc
    │           ├── templates
    │           ├── theme.css
    │           ├── themes
    │           ├── tmp
    │           ├── tool-options
    │           │   ├── gimp-airbrush-tool
    │           │   ├── gimp-align-tool
    │           │   ├── gimp-brightness-contrast-tool
    │           │   ├── gimp-bucket-fill-tool
    │           │   ├── gimp-by-color-select-tool
    │           │   ├── gimp-cage-tool
    │           │   ├── gimp-clone-tool
    │           │   ├── gimp-color-picker-tool
    │           │   ├── gimp-convolve-tool
    │           │   ├── gimp-crop-tool
    │           │   ├── gimp-curves-tool
    │           │   ├── gimp-dodge-burn-tool
    │           │   ├── gimp-ellipse-select-tool
    │           │   ├── gimp-eraser-tool
    │           │   ├── gimp-flip-tool
    │           │   ├── gimp-foreground-select-tool
    │           │   ├── gimp-free-select-tool
    │           │   ├── gimp-fuzzy-select-tool
    │           │   ├── gimp-gegl-tool
    │           │   ├── gimp-gradient-tool
    │           │   ├── gimp-handle-transform-tool
    │           │   ├── gimp-heal-tool
    │           │   ├── gimp-ink-tool
    │           │   ├── gimp-iscissors-tool
    │           │   ├── gimp-levels-tool
    │           │   ├── gimp-measure-tool
    │           │   ├── gimp-move-tool
    │           │   ├── gimp-mypaint-brush-tool
    │           │   ├── gimp-offset-tool
    │           │   ├── gimp-operation-tool
    │           │   ├── gimp-paintbrush-tool
    │           │   ├── gimp-pencil-tool
    │           │   ├── gimp-perspective-clone-tool
    │           │   ├── gimp-perspective-tool
    │           │   ├── gimp-rect-select-tool
    │           │   ├── gimp-rotate-tool
    │           │   ├── gimp-scale-tool
    │           │   ├── gimp-shear-tool
    │           │   ├── gimp-smudge-tool
    │           │   ├── gimp-text-tool
    │           │   ├── gimp-threshold-tool
    │           │   ├── gimp-transform-3d-tool
    │           │   ├── gimp-unified-transform-tool
    │           │   ├── gimp-vector-tool
    │           │   ├── gimp-warp-tool
    │           │   └── gimp-zoom-tool
    │           ├── tool-presets
    │           ├── toolrc
    │           └── unitrc
    └── .local
        └── share
            └── recently-used.xbel

Made some new progress! I actually went back through all my snappshots in Tumbleweed.

Based on the output of cat /etc/os-release, I determined the last known working release on my end where AppImage plus .home worked was Version_ID=‘20251108’ and my next snaphot where the behavior changed/broke was Version_ID=‘20251110’.

Based on this link, (https://openqa.opensuse.org/snapshot-changes/opensuse/Tumbleweed/) there are two dates/snapshots that could be where things changed:

20251110 - BROKEN
20251109 - UNSURE (due to no spanshot on my end to test)
20251108 - WORKS

I’ll read through to try and see what could possibly be the date and package update that caused this.

I think I found what is causing this.

This last bullet point on the update notes for aaa-base 20251109

==== aaa_base ====
Version update (84.87+git20250903.33e5ba4 → 84.87+git20251030.441f926)
Subpackages: aaa_base-extras

  • Update to version 84.87+git20251030.441f926:
    • Add systemd to /etc/nsswitch.conf [bsc#1250513]
    • Add group-directories-first option
    • prevent normal users from accessing dmesg (bsc#1249686)
    • Use explicit defaults for XDG environment variables

PR about the bullet point (Use explicit defaults for XDG environment variables by gmbr3 · Pull Request #174 · openSUSE/aaa_base · GitHub)

1 Like

Have you verified it by usetting the XDG_*_HOME variables before starting AppImage?

Hi.

Yes, it works.

I just made a basic script to unset and run the AppImage.

#!/bin/bash
unset XDG_CACHE_HOME XDG_CONFIG_HOME XDG_DATA_HOME XDG_STATE_HOME XDG_RUNTIME_DIR
exec ./GIMP.appimage "$@"

The GIMP.appimage.home is respected now.

Results on latest Tumbleweed release running GIMP.appimage with a directory named GIMP.appimage.home beside it:

example@Tumbleweed:~/Documents> tree -a
.
├── GIMP.appimage
├── GIMP.appimage.home
│   ├── .cache
│   │   ├── babl
│   │   ├── dconf
│   │   │   └── user
│   │   ├── fontconfig
│   │   │   ├── 3830d5c3ddfd5cd38a049b759396e72e-le64.cache-9
│   │   │   ├── 4b31aef11cb0687b6d280d34cbe23592-le64.cache-9
│   │   │   ├── 5ca8086aeacc9c68e81a71e7ef846b3b-le64.cache-9
│   │   │   ├── 7ef2298fde41cc6eeb7af42e48b7d293-le64.cache-9
│   │   │   ├── 8d4af663993b81a124ee82e610bb31f9-le64.cache-9
│   │   │   ├── a1c95d6dfc9a7b34f44445cf81166004-le64.cache-9
│   │   │   ├── CACHEDIR.TAG
│   │   │   └── d42e465d3d703735db7577b46e8d64be-le64.cache-9
│   │   ├── gegl-0.4
│   │   │   └── swap
│   │   └── gimp
│   │       └── 3.0
│   ├── .config
│   │   ├── GIMP
│   │   │   └── 3.0
│   │   │       ├── action-history
│   │   │       ├── backups
│   │   │       ├── brushes
│   │   │       ├── colorrc
│   │   │       ├── contextrc
│   │   │       ├── controllerrc
│   │   │       ├── CrashLog
│   │   │       ├── curves
│   │   │       ├── devicerc
│   │   │       ├── dockrc
│   │   │       ├── dynamics
│   │   │       ├── environ
│   │   │       ├── extensionrc
│   │   │       ├── filters
│   │   │       ├── fonts
│   │   │       ├── fractalexplorer
│   │   │       ├── gfig
│   │   │       ├── gflare
│   │   │       ├── gimprc
│   │   │       ├── gimpressionist
│   │   │       ├── gradients
│   │   │       ├── icons
│   │   │       ├── internal-data
│   │   │       │   └── custom.ggr
│   │   │       ├── interpreters
│   │   │       ├── levels
│   │   │       ├── modifiersrc
│   │   │       ├── modules
│   │   │       ├── palettes
│   │   │       ├── parasiterc
│   │   │       ├── patterns
│   │   │       ├── pluginrc
│   │   │       ├── plug-ins
│   │   │       ├── scripts
│   │   │       ├── sessionrc
│   │   │       ├── shortcutsrc
│   │   │       ├── tags.xml
│   │   │       ├── templaterc
│   │   │       ├── templates
│   │   │       ├── theme.css
│   │   │       ├── themes
│   │   │       ├── tmp
│   │   │       ├── tool-options
│   │   │       │   ├── gimp-airbrush-tool
│   │   │       │   ├── gimp-align-tool
│   │   │       │   ├── gimp-brightness-contrast-tool
│   │   │       │   ├── gimp-bucket-fill-tool
│   │   │       │   ├── gimp-by-color-select-tool
│   │   │       │   ├── gimp-cage-tool
│   │   │       │   ├── gimp-clone-tool
│   │   │       │   ├── gimp-color-picker-tool
│   │   │       │   ├── gimp-convolve-tool
│   │   │       │   ├── gimp-crop-tool
│   │   │       │   ├── gimp-curves-tool
│   │   │       │   ├── gimp-dodge-burn-tool
│   │   │       │   ├── gimp-ellipse-select-tool
│   │   │       │   ├── gimp-eraser-tool
│   │   │       │   ├── gimp-flip-tool
│   │   │       │   ├── gimp-foreground-select-tool
│   │   │       │   ├── gimp-free-select-tool
│   │   │       │   ├── gimp-fuzzy-select-tool
│   │   │       │   ├── gimp-gegl-tool
│   │   │       │   ├── gimp-gradient-tool
│   │   │       │   ├── gimp-handle-transform-tool
│   │   │       │   ├── gimp-heal-tool
│   │   │       │   ├── gimp-ink-tool
│   │   │       │   ├── gimp-iscissors-tool
│   │   │       │   ├── gimp-levels-tool
│   │   │       │   ├── gimp-measure-tool
│   │   │       │   ├── gimp-move-tool
│   │   │       │   ├── gimp-mypaint-brush-tool
│   │   │       │   ├── gimp-offset-tool
│   │   │       │   ├── gimp-operation-tool
│   │   │       │   ├── gimp-paintbrush-tool
│   │   │       │   ├── gimp-pencil-tool
│   │   │       │   ├── gimp-perspective-clone-tool
│   │   │       │   ├── gimp-perspective-tool
│   │   │       │   ├── gimp-rect-select-tool
│   │   │       │   ├── gimp-rotate-tool
│   │   │       │   ├── gimp-scale-tool
│   │   │       │   ├── gimp-shear-tool
│   │   │       │   ├── gimp-smudge-tool
│   │   │       │   ├── gimp-text-tool
│   │   │       │   ├── gimp-threshold-tool
│   │   │       │   ├── gimp-transform-3d-tool
│   │   │       │   ├── gimp-unified-transform-tool
│   │   │       │   ├── gimp-vector-tool
│   │   │       │   ├── gimp-warp-tool
│   │   │       │   └── gimp-zoom-tool
│   │   │       ├── tool-presets
│   │   │       ├── toolrc
│   │   │       └── unitrc
│   │   ├── gtk-3.0
│   │   └── ibus
│   │       └── bus
│   └── .local
│       └── share
│           └── recently-used.xbel
└── test.sh
1 Like

OK, then you need to report it to AppImage developers. Users are free to set these variables at any time and to any value and AppImage launcher needs to take care of it.