Summary: | DesktopExecParser: Some terminals require "-e <cmd>" while others just take the command directly | ||
---|---|---|---|
Product: | [Frameworks and Libraries] frameworks-kio | Reporter: | Andrew Gunnerson <accounts+kde> |
Component: | general | Assignee: | KIO Bugs <kio-bugs-null> |
Status: | CONFIRMED --- | ||
Severity: | normal | CC: | kdelibs-bugs, magnus.gross21, nate |
Priority: | NOR | ||
Version: | 5.98.0 | ||
Target Milestone: | --- | ||
Platform: | Other | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
Andrew Gunnerson
2022-09-24 18:52:35 UTC
In terminal apps that aren't wezterm or gnome-terminal, does this break if the -e flag is omitted? 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 `--`.) 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 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. *** Bug 460387 has been marked as a duplicate of this bug. *** |