Bug 366793

I'd like to add that konsole 16.08.0's command line help still says this:
$ konsole --help
Usage: konsole [options] [args]
Terminal emulator

Options:
...
  -e <cmd>                   Command to execute. This option will catch all
                             following arguments, so use it as the last option.
...

So according to the documentation, this is supposed to work... ;-)

It seems as parsing the command line is the issue and that everything is seen as an option to konsole.  Using konsole -e "sh -C "echo test"", then it works fine.

(In reply to Raymond Wooninck from comment #2)
> It seems as parsing the command line is the issue and that everything is
> seen as an option to konsole.

Yes, obviously.
But -e should "capture" all following options, and it does in previous konsole versions (which used kdelibs4support, i.e. KCmdLineArgs, for parsing the command line).

>  Using konsole -e "sh -C "echo test"", then it
> works fine.

No, it doesn't.
This displays the following error message in the new konsole window:
/usr/bin/test: /usr/bin/test: cannot execute binary file

konsole -e "sh -c \"echo test\"" would work though.

Btw:
(In reply to Wolfgang Bauer from comment #0)
> (of course it would close immediately again, adding the "--keep" parameter
> should fix that)
I wanted to write "--hold" of course, not "keep".

Btw, this works as expected:
konsole -e echo test
(or konsole --hold -e echo test)
or even:
konsole -e echo This is a test

Both print the given text in the new konsole window.

So the problem only seem to occur if there is another option (with '-') following the -e.

It seems that this bug is also affecting URLs with the "ssh://user@server" schema.

For example: I use KeePassX2 to store all users, passwords and URLs (http//, ssh//, etc.) for all my servers. When I click on a URL, it launches "xdg-open ssh://user@server" and in turn xdg-open launches "ktelnetservice5 ssh://user@server". Before 16.08.0, Konsole was launched with a SSH session established. Now, ktelnetservice5 just end without results. (In one of my test it shows the message "Unknown option 'l'" but I can't reproduce it anymore. I guess the 'l' option means the 'l' parameter from ssh client so maybe ktelnetservice5 is using the "ssh -l user server" sintax and it raises this bug.)

Yes, for SSH ktelnetservice5 runs "konsole --noclose -e ssh -l username host -p port" (if a username or port is not specified, the corresponding option is omitted),
So this is indeed likely the same issue.

ktelnetservice5 does take the default terminal application from systemsettings though, so you could also change that to xterm as work-around.

*** Bug 367588 has been marked as a duplicate of this bug. ***

I don't know if it's related. 
but on manjaro (arch derivative) since konsole 16.08 octopi (graphical package installer) don't work when it call terminal to install AUR package. seems konsole don't start correctly.
and also someone reported that his shortcut was not working anymore.

downgrading konsole to 16.04 solve the problem.

https://forum.manjaro.org/t/unstable-update-2016-08-30-networkmanager-haskell-plasma-5-7-4/8371/37

commands like 

"konsole -e mpv --fs /mnt/foo.avi also don't work"

--fs is used by konsole and i get Unknown option 'fs'.
although konsole -e "mpv --fs /mnt/foo.avi" is working.

Another combination that doesnt work are spaces inside filenames until they spaces are escaped.

konsole -e "mpv /mnt/data/foo\ 1.mp4" - works
konsole -e "mpv /mnt/data/foo 1.mp4" - doesn't work

please get this fixed and provide the functionality descibed in the help output:

Options: ... -e <cmd> Command to execute. This option will catch all following arguments, so use it as the last option.

Marking confirmed.

Another side-effect is that application desktop shortcuts that include
Terminal=true
no longer work either (see also bug #368949)

appears to be a consequence of porting away from kdelibs4support, which provided support for a plethora of extra command line options, including:
-caption (see bug #368949)

It's not the same regression (but likely also a consequence of the port): Here, we DON'T want to have -c parsed by Konsole at all, it should be treated as an argument to -e.

This breaks at least the debuginfo-install.sh from kdelibs4.

> This breaks at least the debuginfo-install.sh from kdelibs4.

From kde(4)-runtime's DrKonqi, actually.

*** Bug 369040 has been marked as a duplicate of this bug. ***

*** Bug 368899 has been marked as a duplicate of this bug. ***

*** Bug 369297 has been marked as a duplicate of this bug. ***

*** Bug 369314 has been marked as a duplicate of this bug. ***

Indeed the command line parsing of konsole is broken. It parses any option passed after -e as its own. E.g. "konsole -e echo --authors" makes konsole dump the list of its authors.

Will this bug be fixed before 16.12 (currently in beta) releasing? Or we will have to wait to 17.04 (or beyond)?

The cause appears to be a shortcoming in QCommandLineParser in that it has no option syntax for "capture all the remaining arguments after this one", as was the case for KCmdLineArgs and an option starting with '!'.  Some of the required functionality can be restored by setting the parser to not parse options after the first non-option argument:

--- a/src/main.cpp
+++ b/src/main.cpp
@@ -109,6 +109,7 @@ extern "C" int Q_DECL_EXPORT kdemain(int argc, char* argv[])
 
     QSharedPointer<QCommandLineParser> parser(new QCommandLineParser);
     parser->setApplicationDescription(about.shortDescription());
+    parser->setOptionsAfterPositionalArgumentsMode(QCommandLineParser::ParseAsPositionalArguments);
     parser->addHelpOption();
     parser->addVersionOption();
     about.setupCommandLine(parser.data());

but which still fails if the first option after the command name is an option:

konsole --hold -e ls -l main.cpp           => error "Unknown option 'l'."

The workaround is to ensure that the first argument is not an option:

konsole --hold -e ls main.cpp -l           => works

which only works if the command accepts options after non-option arguments; alternatively

konsole --hold -e ls -- -l main.cpp        => works

(In reply to Jonathan Marten from comment #20)
> Some of
> the required functionality can be restored by setting the parser to not
> parse options after the first non-option argument:

Yes, but this requires Qt 5.6 at least.
Probably not a problem for KDE Applications 17.04, but it will prevent distributions that still use Qt 5.5 to backport the fix (I don't know if any of them ship konsole 16.08 though).

> The workaround is to ensure that the first argument is not an option:

Another workaround would be to make the '-e' option not take any arguments at all, then the actual command would be the first positional argument. (disadvantage: QCommandLineParser will not complain if there is no command at all after '-e', and the command itself may not start with a '-' but that can be ignored I suppose)

Another way I see to fix the problem is to parse the command line manually before handing it over to QCommandLineParser, and strip off '-e' and all that follows (and handle it manually).

Actually I experimented myself with both a bit already, but had no time yet to get it into a fully working shape...

Hello,

don't know if my problem is related to this bug, but might be:

Reproducible: always

Steps to reproduce:
1. define global shortcut, e.g., Win+v in systemsettings > global shortcuts, that would run command 'konsole -e vim' (w/o single quotes)
2. use Win+v to launch vim in konsole
3. start another instance of konsole (not tab), either A-F2, launch menu, quick launch widget

Actual result:
konsole is started with vim launched; Works with mc, ncmpcpp. When I go to 'Edit current profile', 'Command' field in 'General' tab does state 'vim' instead of full path to shell executable

Expected result:
Having konsole launched with shell only

Running konsole 16.08.3-r1

However, when the command is 'konsole --name Vim -e vim', next konsole I start works fone. So, this problem can be at least work-arounded :)

Thank you all who have ever worked on KDE :)

(In reply to OndraK from comment #22)
> Steps to reproduce:
> 1. define global shortcut, e.g., Win+v in systemsettings > global shortcuts,
> that would run command 'konsole -e vim' (w/o single quotes)
> 2. use Win+v to launch vim in konsole
> 3. start another instance of konsole (not tab), either A-F2, launch menu,
> quick launch widget
> 
> Actual result:
> konsole is started with vim launched; Works with mc, ncmpcpp. When I go to
> 'Edit current profile', 'Command' field in 'General' tab does state 'vim'
> instead of full path to shell executable

This rather sounds like bug#371863 (and its duplicates), which should be fixed in 16.12.0.

Btw, regarding *this* bug, somebody proposed a patch, which I can confirm is fixing the problems with the '-e' parameter:
https://git.reviewboard.kde.org/r/129677/

> Btw, regarding *this* bug, somebody proposed a patch, which I can confirm is
> fixing the problems with the '-e' parameter:
> https://git.reviewboard.kde.org/r/129677/

thanks, it works for me too

*** Bug 374625 has been marked as a duplicate of this bug. ***

Also prevents usage of konsole as a terminal in QtCreator when parameters are present.

The fix has been committed yesterday:
https://cgit.kde.org/konsole.git/commit/?id=a779c8314a7d27bb4691c220f793540e6f84f6c9