I have been creating and using small servicemenu entries for dolphin for years now. They suddenly stopped working as expected. Here is a sample that used to work but now fails on the shell parameter expansion
# save this to ~/.local/share/kio/servicemenus/test.desktop
[Desktop Action convertToWAV]
Name=Convert To WAV
Icon=video-mpeg
Exec= towav="%f" && ffmpeg -i "$towav" "${towav%.*}".wav
The idea is to extract audio from a video file. Everything works up until the param expansion that just removes everything after the dot. The filename is in the towav var and ffmpeg happily creates a valid wav file, only with the name .wav which unfortunately is kind of invisible in dolphin. Anyway, it seems to be related to the curly braces because something like "$towav ${towav} ${towav%.*}".wav only has the very first file name, the one without braces to the variable.
Any ideas what has changed recently in desktop file exec handling? Is that a bug or a feature? Sometimes things stop working because devs decided the previous implementation did not follow specs to the letter…
If this was working to your satisfaction in Plasma 5 and not anymore in Plasma 6, I assume it is worth a bug report.
Maybe you could first/also try at the KDE forums: https://discuss.kde.org/ to get more information.
Apart from the fact that you say “it worked”, with these sort of things I always ask things like: why do you think that bash is involved? Is this somewhere defined in the definitions of these .desktop files?
I thought this kind of variable value mangling was bash specific and bash is the default on my computers. But I see that it should the same in zsh and ksh. But you are right, I have actually no idea where the desktop file parser sends the exec line to
You think so, but for what? And where is that defined?
As far as I know when a system manager creates a new user (and he did not change anything in what that process does) bash is given to that user as login shell (the user can change that). So there it is a (sort of) default. But I do not know of any other place. And that is not needed either. Every script starts with a “shebang” that defines which interpreter should be used. No default there.
I say so because we had (much) earlier someone who tried to create a systemd unit. The ExecStart= in the [Service] section there is parsed by systemd and what can be there is defined in the docs (e.g. what %. variables can be used). But he thought it was bash interpreted and tried to compress a complete script in it, which failed of course.
specifically through /bin/sh which points to bash here. But maybe we follow RH and have /bin/sh running bash in posix mode. Yep, looks like it. But it should still work. Let me do more trial and error
found it. It is indeed related to systemd. Apparently, kio is doing some limited macro expansion on its own like the %f or %F etc, possibly prepends an “sh -c” and then passes the line to systemd. That, in turn, does what it does for systemd unit ExecStart lines including Environment variables. If a variable is set in the bash command itstelf, it needs to be prefixed with another dollar sign, ie $${towav%.*}