Ensure that AppImages with spaces in the filename work

[probonopd]

Continuation from https://github.com/nomad-desktop/nx-software-center/issues/28

Needs to be investigated whether AppImageKit is at fault or linuxdeployqt or something else.

[TheAssassin]

Just another "missing sanitation" error in our code base...

[KD0BPV]

I think this or a similar issue is also affecting the AppRun binary. I'll list various Exec lines I tried in my .desktop file, and AppRun's error regarding it. The script file referenced is at "//usr/bin/Katawa Shoujo.sh".

Exec="Katawa Shoujo.sh" > Error executing '"Katawa Shoujo.sh"': No such file or directory Exec='Katawa Shoujo.sh' > Error executing ''Katawa': No such file or directory Exec=Katawa\ Shoujo.sh > Error executing 'Katawa\': No such file or directory

[TheAssassin]

@KD0BPV To be fair, executable names with spaces are something totally awkward...

[KD0BPV]

No argument from me there. But then, I'm not the author of that app. lol. And since the standards involved allow it (Linux kernel, FreeDesktop .desktop files, desktop environments, etc), it needs to be handled.

In the end, I patched the shell script to properly launch the python environment that the app needs, regardless of the script's filename, and changed the Exec line and filename accordingly. My AppImage works perfectly after that. :smile:

[TheAssassin]

Didn't try to excuse this bug at all. Just a comment about antipatterns when choosing executable filenames...

[probonopd]

AppImageKit wants to support file names with spaces in them. If we currently don't, then it's a (one or more) bug.

[KurtPfeifle]

@probonopd:

"AppImageKit wants to support file names with spaces in them. If we currently don't, then it's a (one or more) bug."

The [AppImageSpec draft document]() explicitly demands tolerance for spaces in file system paths as well as in AppImage filenames for both, type 1 and type 2 AppImages:

MUST work even when stored in a filesystem path that contains blanks or when stored with a file name that contains blanks

[TheAssassin]

@KurtPfeifle jfyi, that part is apparently discussing the file path of the AppImage, not paths within the AppImage.

[probonopd]

We want to support spaces in paths both outside and inside of the AppImage. For the latter, AppRun also needs to be coded accordingly. I hope ours are - but we need to check this.

[TheAssassin]

I assume the problem is the lack of escaping of the Exec=<filename> filename part. I haven't got to looking into this yet.

[probonopd]

Good point. It may be necessary to use Exec=sh -c "Katawa Shoujo.sh".

References:

• https://askubuntu.com/questions/189822/how-to-escape-spaces-in-desktop-files-exec-line
• https://standards.freedesktop.org/desktop-entry-spec/latest/ar01s07.html

[probonopd]

But https://github.com/nomad-desktop/nx-software-center/issues/28 seems to be about spaces in the name of the AppImage itself.

[KD0BPV]

As the original author of nomad-desktop/nx-software-center#28, yes. That is what we discovered in that issue: An .AppImage file with spaces in the name does not get it's filename properly handled. In that case, it caused the run-time to believe the mount failed, because it was looking in the wrong (non-existing) location for the mounted image.

I did some testing, and I think you're right about the sh -c "..." point. The .desktop files don't appear to handle spaces, quotes, and escaped characters the same way that shells do, so the AppRun issue I was having may have been my own fault. I'll test to confirm, and let you know the results.

[KD0BPV]

Ok, yeah. There does NOT appear to be a problem with the AppRun binary after all. I removed my patch from Katawa_Shoujo.sh, renamed it accordingly, and changed the .desktop to Exec=sh -c "Katawa Shoujo.sh", and now the game launches as expected.

[KurtPfeifle]

It would be really ridiculous to demand support for paths and file names with spaces only for places outside the AppImage, but not for paths inside the squashfs file system. If the AppImageSpec leaves room for misinterpretation here, it should be fixed.

[KD0BPV]

I was wrong, there is an issue with AppRun, but not what I originally thought. Please see #690.

[TheAssassin]

@KurtPfeifle I agree. Please send a PR.

[TheAssassin]

Related issue: #706.