All launchers or just some?
Are these .desktop files you created or are they from the system?
If they are your own please include a sample.
Enhancement:- Please also tell us which application is concerned, and where it was installed from (eg: default repo’s, AUR; flatpak; etc).
Not all the launchers fail to launch. I noticed that all the launchers that launched a bash script failed.
Here’s an example of a shortcut that doesn’t work:
[Desktop Entry]
Name=Word
Exec=/home/aurel/.local/bin/winapps word-o365 %F
Terminal=false
Type=Application
Icon=/home/aurel/.local/share/winapps/apps/word-o365/icon.svg
StartupWMClass=Microsoft Word
Comment=Microsoft Word
Categories=WinApps;Office
MimeType=application/msword;application/vnd.openxmlformats-officedocument.wordprocessingml.document;application/vnd.openxmlformats-officedocument.wordprocessingml.template;application/vnd.ms-word.document.macroEnabled.12;application/vnd.ms-word.template.macroEnabled.12;
It’s from a tool called winapps that basically opens a RDP session on a windows KVM with a windows app in it. I know the tool works because when i launch the command in the exec setting manually on a cli, it works.
I’m unfamiliar with winapps, sorry.
Have you made the .desktop files executable?
No problem, yes, they are:
ls -al .local/share/applications/word-o365.desktop
-rwxr-xr-x 1 aurel aurel 520 7 oct 09:49 .local/share/applications/word-o365.desktop
I dont know what winapps looks like, but you said it is a bash script
>>
Exec=/usr/bin/bash "/home/aurel/.local/bin/winapps word-o365 %F"
2 Likes
I missed that completely. Yes, that should probably help. 
.desktop files don’t need execute permission. 
No, not if popups are something you enjoy!
None of my .desktop files have execute permission, and yet I don’t get any of those popups.
Besides, those popups have nothing to do with the actual on-disk permissions. They are for setting the default action on an executable file, which itself is called upon by its .desktop file.
Yes, and by clicking the ‘Execute’ button, ergo, it’s… executable.
When a .desktop file is launched from it’s usual location, that popup is probably never seen, however, from a .desktop created in the menu, or on the desktop proper, it can be.
Doesn’t have anything to do with the filesystem permissions. A .desktop file is just a plain text file that is parsed by any XDG-capable desktop environment for determining what to do with the target it points at.
True. However, from an esoteric standpoint an ‘execute’ button still makes the thing launch, if “is executable” is not already selected it the .desktop file’s Permissions tab.
Yes, but OP stated the following… 
… which is why I wrote…
But…
That permissions tab sets the filesystem permissions on the file. This is a completely different thing.
I think I ignored that; for all the obvious reasons.
Unfortunately, some of the packagers don’t really understand this whole permissions issue and install packages with 755 permissions on their .desktop files under /usr/share/applications — I’ve already had to correct this several times.
I guess that’s what you can expect when you get packagers — even over at Arch, which is Manjaro’s upstream — who grew up on Microsoft Windows and Android, and who’ve ever even seen a UNIX system from up close (if they even know what it is). 
Anyway, returning to the topic, I think @cscs nailed it in post #7. The OP should get back to us on that. 
I’ve seen it: install -Dm755 ... whereas Dm644 is probably more appropriate, unless memory fails me.
1 Like
Well, I don’t know enough about packaging to parse what -Dm stands for. If it stands for a directory — the D? — then 755 is usually appropriate. Not always, but usually. But even then they still get it wrong from time to time. 
I’m likely in the same boat; most of what I’ve learned was borne out of necessity, for example, when a provided PKGBUILD was incomplete, or totally borked. My understanding is that the -DmXXX signifies directory permissions; the XXX the permission attribute itself, being dependent on where the file should be installed to; for example:
install -Dm644 "${srcdir}/${pkgname}.desktop" --> `${pkgdir}/usr/share/applications`
install -Dm755 "${srcdir}/${pkgname}.sh" --> `${pkgdir}/usr/bin`
… or similar. Note, this is pseudo-code – do not try this at home!
I haven’t needed to delve too deep thus far. @dmt might have something to add though.
1 Like
From man install:
-D create all leading components of DEST except the last, or all components of --target-directory, then copy SOURCE to DEST
-m, --mode=MODE
set permission mode (as in chmod), instead of rwxr-xr-x
I wasn’t sure if my interpretation, that -D made parents and the -m set the perms for the file, was entirely correct, so:
% ls -l
total 20
-rw-r--r-- 1 dm dm 16743 Oct 8 10:40 env
% install -Dm644 env testy2/env
% ls -l
total 24
-rw-r--r-- 1 dm dm 16743 Oct 8 10:40 env
drwxr-xr-x 2 dm dm 4096 Oct 8 10:42 testy2
ls -l testy2
total 20
-rw-r--r-- 1 dm dm 16743 Oct 8 10:42 env
2 Likes