[SOLVED] [KDE] Application startup command changes?

0BADC0DE · 2022-03-23 07:23:25

Hi all.
I have a dual-mode KDE/Plasma desktop that I boot with tbsm (as sddm is still at v0.19) where I can choose between Wayland and X.org.
For this reason I have modified some application startup commands in order to detect which mode I am in.
For example, my Chromium browser startup command looks like this:

[[ "$XDG_SESSION_TYPE" == "wayland" ]] && /usr/bin/chromium --enable-features=UseOzonePlatform --ozone-platform=wayland %U || /usr/bin/chromium %U

It has worked flawlessly until a few days ago (I do daily package updates) when I noticed that my browser was using XWayland instead of (just) Wayland.
The tool xlsclients was listing my browser process as active despite I was I Wayland. Weird.

With some investigation I tracked the issue down to the fact that the actual startup command to be run is:

/bin/sh -c [[ "$XDG_SESSION_TYPE" == "wayland" ]] && /usr/bin/chromium --enable-features=UseOzonePlatform --ozone-platform=wayland %U || /usr/bin/chromium %U

which in turn badly fails with this error even in the command line:

wayland: -c: line 2: unexpected token `EOF' in conditional command
wayland: -c: line 2: syntax error: unexpected end of file

So my first part of command is failing and the second part, the one after '||', is run.

If I run the command without the '/bin/sh -c' then it trivially work, so it could either be the /bin/sh itself or the way it is called by the launcher.
I checked there is a blank before ']]' (the only case that came to my mind).
As this used to work and I haven't changed anything in my application startup command, I can imagine something has changed elsewhere.
As I am using mostly Wayland, I removed that conditional part from the command and running the applications in Wayland mode.
But I don't like this bad workaround and would like to file a bug (if it is a bug) or make a real solution (if it is not).

Is there anyone who has an idea?

[UPDATE]
It was likely a regression. Now it's working again.

Last edited by 0BADC0DE (2022-04-06 11:21:34)

seth · 2022-03-23 13:25:45

%U isn't meaningful shell syntax, so unless it's pre-expanded by whatever the desktop service is, you'd want it to be "$@"
Also the double bracket [[]] is a bashism (no idea whether that's a problem w/ your /bin/sh)

0BADC0DE · 2022-03-23 13:32:52

seth wrote:

%U isn't meaningful shell syntax, so unless it's pre-expanded by whatever the desktop service is, you'd want it to be "$@"
Also the double bracket [[]] is a bashism (no idea whether that's a problem w/ your /bin/sh)

Default startup command uses %U and I presume is a KDE/Plasma thing when using that menu item to open a file.

Similarly, '[[ ... ]]' used to work until a few days ago in the very same menu item. And, yes, /bin/sh *is* bash.

Will try you hints, though.

[UPDATE]
This works from CLI with no error and correct branch selection:

/bin/sh -c "[[ $XDG_SESSION_TYPE == wayland ]] && /usr/bin/chromium --enable-features=UseOzonePlatform --ozone-platform=wayland %U || /usr/bin/chromium %U"

And it works also for menu item command without the "/bin/sh -c" (which is added by KDE menu).
But why do I need this workaround when it used to work?

Last edited by 0BADC0DE (2022-03-23 13:54:52)

V1del · 2022-03-23 13:45:35

kio 5.92 contains https://invent.kde.org/frameworks/kio/- … 5dd80c9eb7 which probably lead to some new behaviour here, this was subsequently reverted in https://invent.kde.org/frameworks/kio/- … de67dbd985 so presumably this will work as it used to on the next frameworks release.

in all technicality the original version is also incorrect according to the discussion in the related bug (and the linked spec) https://bugs.kde.org/show_bug.cgi?id=448859 so by explicitly specifying a proper sh context you are generally "more" correct anyway.

OT: while /bin/sh is a symlink to bash, invoking bash via sh-symlink has certain stipulations (... and bash partially adjust it's behaviour to be more sh-compatible) and you should not rely on bashisms in scripts explicitly invoked by /bin/sh because it is not guaranteed to be bash. This will work on your system and be fine for this context but might trip up should you ever decide you didn't want /bin/sh to be a symlink to bash.

Last edited by V1del (2022-03-23 13:57:18)

0BADC0DE · 2022-03-23 14:07:53

V1del wrote:

OT: while /bin/sh is a symlink to bash, invoking bash via sh-symlink has certain stipulations and you should not rely on bashisms in scripts explicitly invoked by /bin/sh because it is not guaranteed to be bash. This will work on your system and be fine for this context but might trip up should you ever decide you didn't want /bin/sh to be a symlink to bash.

I think bash behaves a little bit different when called as "sh".
Nonetheless, it used to work. The point is, IMHO, on how the command string is passed to "/bin/sh -c": a single string is OK, a split string is not.

Arch Linux

#1 2022-03-23 07:23:25

[SOLVED] [KDE] Application startup command changes?

#2 2022-03-23 13:25:45

Re: [SOLVED] [KDE] Application startup command changes?

#3 2022-03-23 13:32:52

Re: [SOLVED] [KDE] Application startup command changes?

#4 2022-03-23 13:45:35

Re: [SOLVED] [KDE] Application startup command changes?

#5 2022-03-23 14:07:53

Re: [SOLVED] [KDE] Application startup command changes?

Board footer