AppImages with spaces in the file name don't run after being integrated

[afland]

Describe the bug When I download an AppImage with a space in the file name, I can run it with AppImageLauncher and choose "Integrate and Run." However, when I execute the newly created .desktop file, it'll say example.appimage not found or something like that. AppImageLauncher did successfully put the appimage in ~/applications, but the appimage won't run unless I replace the space with a character like "-" This wouldn't be a big deal if I could just rename a downloaded .appimage once, but the error resurfaces everytime the application updates itself. It'll also be difficult for many users to figure out why their appimage isn't launching.

Expected behavior AppImageLauncher either automatically replaces the space with another character (including everytime the application updates itself) or somehow is changed to be able to launch even with spaces.

To Reproduce Steps to reproduce the behavior:

1. Download lunar client, for example
2. Run with appimagelauncher
3. Integrate and run
4. See not found error

System, software and AppImage information Kubuntu 21.10, kde plasma

AppImageLauncher version installed: 202110042218-stable-0f91801~ubuntu21.10.1 (using ubuntu ppa)

List of AppImages you tried: Lunar client --> https://www.lunarclient.com/download/

[TheAssassin]

Please fill in the missing information (most notably, AppImageLauncher version).

Also, you need to post the URL of your AppImage.

[afland]

Please fill in the missing information (most notably, AppImageLauncher version).

Also, you need to post the URL of your AppImage.

done. The issue seems to be with .desktop files just not being able to launch anything with a space in the name, so maybe the best approach is to automatically replace spaces with another character (both on first run and when appimage updates itself)

[wsbankenstein]

@afland I am experiencing the exact same issue.

The AppImage can still be launched from the command line, but the desktop launcher does nothing visible. I believe the reason for this is the spaces in the filename being interpreted as literal spaces in the desktop launcher's Exec field. Removing the spaces from the filename and reintegrating fixed the issue.

To reproduce

1. Integrate an AppImage which has spaces in the original filename.
2. Try to run it from the desktop launcher.
3. Manually open the generated desktop launcher and note the literal space in Exec=/path/to/My Application-1.2.3_e758d6471ffd7dda4b4fbe2eee6ab1fc

System information OS: Pop!_OS 21.10 x86_64 Kernel: 5.15.23-76051523-generic Shell: bash 5.1.8 DE: GNOME 40.5 WM: Mutter WM Theme: Pop

AppImageLauncher version 2.2.0 (git commit 0f91801), built on 2021-10-04 22:32:13 UTC

List of AppImages tried

• LMMS (bug did not occur): https://github.com/LMMS/lmms/releases/download/v1.3.0-alpha.1/lmms-1.3.0-alpha.1.102%2Bg89fc6c9-linux-x86_64.AppImage
• Lunar Client (bug occurred): https://www.lunarclient.com/download/ (download for Linux - original filename Lunar Client-2.9.4.AppImage)
• Lunar Client with modified filename (bug did not occur): same as above, but with the filename manually changed to lunar-client-2.9.4.AppImage before integration

@TheAssassin This issue should not have been dismissed instead of fixed. The reason neither of us have given you the direct download link for Lunar Client is that there is no such link. Not even by viewing the page source was I able to find it. You just have to click twice instead of once, mate. I apologise in case you have been unable to actually fix this issue within the last two months.

[shoogle]

This issue should not have been dismissed instead of fixed... you have been unable to actually fix this issue within the last two months.

This is open source software and maintainers are working for free. They will fix it if an when they have time. If you want it fixed sooner then feel free to fix it yourself and submit a PR.

[TheAssassin]

This issue should not have been dismissed instead of fixed

Thanks @shoogle. If the issue would have been dismissed, it would be closed. I try my best to find some time to fix bugs, and seeing people begging is not a good motivation to focus on this project...

Thanks for the additional information, though.

[wsbankenstein]

@TheAssassin My rhetoric may not have been the friendliest, I apologise.

@shoogle I understand. It is unfortunate that the only way to not be ignored on the Internet is to argue. As for the pull request, I have never worked as a software developer and therefore do not consider myself the most credible person to propose changes to a project I have no relation to. Might give it a go though.

[wsbankenstein]

Although I tried quite hard, I did not manage to successfully build from source. It may be worth noting that I have zero experience with cmake.

Anyway, I couldn't test the thing. I do believe that a simple std::replace(fileName.begin(), fileName.end(), ' ', '') in the path building function in src/shared/shared.cpp will fix the issue without interfering with other parts of the code, but, once again, I can never be sure. My "experience" with C++ falls short of things like pointers and custom namespaces.

TL;DR: I did my best, even though that's not very much. Thank you for tolerating me.

[shoogle]

@wsbankenstein, well done for trying! Programming isn't easy by any means, but you put the effort in when not everybody would so thanks for that!

[TheAssassin]

Anyway, I couldn't test the thing. I do believe that a simple std::replace(fileName.begin(), fileName.end(), ' ', '') in the path building function in src/shared/shared.cpp will fix the issue without interfering with other parts of the code, but, once again, I can never be sure. My "experience" with C++ falls short of things like pointers and custom namespaces.

I suspect the bug is within libappimage, and it should be fixed there then. Let's not implement more workarounds around libappimage.

[TheAssassin]

Reproducible. Needs fixing in libappimage, though. It's the TryExec key, apparently, not the Exec key, as far as I can see, which needs to be quoted. I've tried it with Popsicle, Xournal++ and TeXstudio.

[TheAssassin]

I opened a PR to a dependency of libappimage: https://github.com/azubieta/xdg-utils-cxx/pull/19

Once merged, libappimage can be fixed. All we have to do is update to make AppImageLauncher work then.

[night199uk]

I hit this exact same issue with Shutter Encoder 16.4; which uses the following filename: Shutter Encoder 16.4 Linux 64bits.AppImage

After installation with AppImageLauncher, the created .desktop file has this: Exec=/home/xxxxxx/.local/Applications/Shutter Encoder 16.4 Linux 64bits_xxxxxxxxxx.AppImage

Per this bug, it seems like spaces in .desktop files need to be escaped; but AppImageLauncher (or libappimage perhaps?) are not correctly escaping when creating the desktop file perhaps? https://askubuntu.com/questions/189822/how-to-escape-spaces-in-desktop-files-exec-line

I see the upstream libappimage bug has been merged back in March. Any chance you could take a look back again at this one please @TheAssassin ?

[TheAssassin]

Please try the latest continuous release.