Bug 459616 - DesktopExecParser: Some terminals require "-e <cmd>" while others just take the command directly
Summary: DesktopExecParser: Some terminals require "-e <cmd>" while others just take t...
Status: CONFIRMED
Alias: None
Product: frameworks-kio
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: 5.98.0
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: KIO Bugs
URL:
Keywords:
: 460387 (view as bug list)
Depends on:
Blocks:
 
Reported: 2022-09-24 18:52 UTC by Andrew Gunnerson
Modified: 2022-10-14 19:09 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Gunnerson 2022-09-24 18:52:35 UTC
SUMMARY

It seems that terminal emulators generally allow spawning an application inside a new window with either "<terminal> -e <command>" or just "<terminal> <command>". Currently, only the former (with "-e") is supported in DesktopExecParser.

This causes "Terminal=true" desktop files to fail to launch when the default terminal application is set to one that doesn't use/support "-e".

STEPS TO REPRODUCE
1. Set the default terminal to an application that doesn't use "-e" (eg. wezterm or gnome-terminal)
2. Create a desktop file with "Terminal=true"
3. Launch the desktop file

OBSERVED RESULT

The default terminal fails to launch with some error message about "-e" being an unknown argument (or similar).

EXPECTED RESULT

The default terminal should launch successfully with the specified command.

SOFTWARE/OS VERSIONS
Windows: n/a
macOS: n/a
Linux/KDE Plasma: Fedora 36
KDE Plasma Version: 5.25.5
KDE Frameworks Version: 5.98.0
Qt Version: 5.15.5

ADDITIONAL INFORMATION

I'm not sure there's a clean/foolproof way to make this work. I don't think there's any sort of metadata (in the .desktop or similar) that describes how a terminal expects a command to be passed to it.
Comment 1 Nate Graham 2022-09-26 19:01:47 UTC
In terminal apps that aren't wezterm or gnome-terminal, does this break if the -e flag is omitted?
Comment 2 Andrew Gunnerson 2022-09-26 21:55:04 UTC
Unfortunately, yes. With xterm, it fails when parsing the arguments without `-e`. With Konsole,

    konsole -e bash -c 'echo abc'

runs `bash -c 'echo abc'` as expected, but:

    konsole -- bash -c 'echo abc'

seems to just ignore the extra arguments. (And arguments cannot be parsed without the `--`.)
Comment 3 Andrew Gunnerson 2022-09-26 22:42:36 UTC
I went through Arch Wiki's list of terminal emulators and tested most of them: https://wiki.archlinux.org/title/List_of_applications#Terminal_emulators

Looks like there are many different ways with how they accept the commands :(

Requires `-e` where `-e` signals the end of argument parsing and all further arguments specify the command to run:
- alacritty
- konsole
- lxterminal
- mlterm
- putty (documented in the help output, but the argument parser fails to handle -e)
- qterminal (fails to run command if it contains arguments starting with dash. Eg. `-c` in `qterminal -e bash -c 'sleep 5'`)
- roxterm
- tilix
- urxvt
- xterm

Requires `-e`, but requires the command to be specified as a single string:
- guake
- mate-terminal
- pantheon-terminal (does not exit after command completion)
- terminator
- xfce4-terminal

Requires no flag after the Exec= command in the .desktop file:
- gnome-terminal
- kitty
- wezterm

Requires no flag, but also supports `-e` optionally:
- st

Don't support running a command at all:
- liri-terminal
- yakuake
Comment 4 Nate Graham 2022-09-27 14:48:00 UTC
Thanks for collecting that info! Seems like an unfortunate situation.

Probably the most robust approach is to propose a FreeDesktop spec for how this should be handled, consult with terminal devs to get buy-in, and then submit patches to terminals that become un-compliant after it's accepted and finalized.
Comment 5 Nate Graham 2022-10-14 19:09:46 UTC
*** Bug 460387 has been marked as a duplicate of this bug. ***