search

TheAssassin / AppImageLauncher

Helper application for Linux distributions serving as a kind of "entry point" for running and integrating AppImages
https://assassinate-you.net/tags/appimagelauncher/
MIT License
5.17k stars 244 forks source link

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

Open afland opened 2 years ago

afland commented 2 years ago

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 commented 2 years ago

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

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

afland commented 2 years ago

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 commented 2 years ago

@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

@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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

@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 commented 2 years ago

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 commented 2 years ago

@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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 1 year ago

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 commented 1 year ago

Please try the latest continuous release.