When running Konsole with this command: $ konsole -e echo "foo" && sleep 3 && echo "bar" && sleep 3 && echo "closing" ... Konsole used to 1) create a new Konsole window, 2) execute the command string after -e, and 3) send the output to the new Konsole window. As far as I can tell, it does not do these things anymore. To duplicate this behaviour, press Alt-Space to open the Run command, paste in the command shown above, and notice that Konsole blinks into existence momentarily, disappears, and the command doesn't get a chance to run to completion, displaying its progress. This change was noticed after upgrading to KDE Frameworks 5.28.0 / Konsole 16.04.3 / Qt 5.6.1 as part of Kubuntu 16.10.
The command line had a lot of changes to move off the old kdelibs4support libraries. If you add --noclose, you can see that somethings not correct.
(In reply to Michael from comment #0) > When running Konsole with this command: > > $ konsole -e echo "foo" && sleep 3 && echo "bar" && sleep 3 && echo "closing" > > ... Konsole used to 1) create a new Konsole window, 2) execute the command > string after -e, and 3) send the output to the new Konsole window. I just tried that with konsole 4.14.3, and it doesn't do that either. And actually I don't see how it could, and how this is a problem in konsole... I think it's the shell that interprets '&&' *before* the command is called. So in the end you actually run this: $ konsole -e echo "foo" $ sleep 3 $ echo "bar" $ sleep 3 $ echo "closing" And that's the behavior I see when trying that here, i.e. "bar" and "closing" are printed in the original konsole window (if run in konsole). And the first command does open a new konsole window but it closes immediately again (so you might not see it at all), because the "--noclose" is missing. Btw, the behavior is exactly the same if you use xterm instead of konsole in the mentioned command.
PS, this should work like you expect it to, it does here with Konsole 17.04 at least: konsole --noclose -e sh -c 'echo foo && sleep 3 && echo "bar" && sleep 3 && echo "closing"'
(In reply to Kurt Hindenburg from comment #1) > The command line had a lot of changes to move off the old kdelibs4support > libraries. > > If you add --noclose, you can see that somethings not correct. Yes, thank you, that's what I'm alluding to, that there has been a change that breaks old scripts' behaviours. If I include --noclose, then that forces konsole to stay open, which is not how it worked previously: a script would terminate, and konsole would close afterwards, as expected.
Created attachment 105152 [details] contains a one line script to download youtube videos
(In reply to Wolfgang Bauer from comment #3) > PS, this should work like you expect it to, it does here with Konsole 17.04 > at least: > konsole --noclose -e sh -c 'echo foo && sleep 3 && echo "bar" && sleep 3 && > echo "closing"' Thank you for addressing this issue! Yes, adding the --noclose keeps Konsole open, but that's a different functionality than what we had before. Allow me to explain further. I used to have long, one-liner scripts that were embedded in a .desktop file, like the one I just attached. A client could click on the .desktop file and it would create a Konsole window, run the script, log the results inside the window, and when the script was over, Konsole would disappear. Perfect. Just as expected. For example, here's the relevant line that gets executed in a .desktop file that used to work: Exec=konsole -e echo "" && downloads="$HOME/Downloads" && echo "Waiting..." | toilet --font term --filter border && kdialog ${WINDOWID:+--attach $WINDOWID} --caption ' ' --title ' ' --inputbox "Paste a Youtube, Vimeo, or virtually any video URL here to get the video:" "URL or video code" 2>/dev/null > /tmp/yturl && echo "Getting the file name from online..." | toilet --font term --filter border && { youtube-dl --get-filename --output "$downloads/%(title)s.%(ext)s" --batch-file /tmp/yturl > /tmp/ytpath && thepath="$(cat /tmp/ytpath)" && echo "Downloading the video..." | toilet --font term --filter border && youtube-dl --batch-file /tmp/yturl --newline --no-mtime --output "$thepath" && qdbus org.freedesktop.FileManager1 /org/freedesktop/FileManager1 org.freedesktop.FileManager1.ShowItems "$thepath" "1"; } || { size=$( wc -c < "/tmp/yturl" ) && if [ $size -gt 1 ]; then kdialog ${WINDOWID:+--attach $WINDOWID} --caption ' ' --title ' ' --msgbox "Sorry, unable to download “$(cat /tmp/yturl)”" 2>/dev/null; else kdialog ${WINDOWID:+--attach $WINDOWID} --caption ' ' --title ' ' --msgbox "Cancelled." 2>/dev/null; fi; } Now this .desktop file won't work. Konsole has removed needed functionality. I've attached the .desktop file to play with.
To clarify, the command: konsole -e echo "foo" && sleep 3 && echo "bar" && sleep 3 && echo "closing" was just a simplification of my issue without others having to parse my long one-liners. The above command will no longer work in a .desktop file, whereas it would've before. That's my point.
konsole --hold -e sh -c 'echo foo && sleep 3 && echo "bar" && sleep 3 && echo "closing"' The above works for me, Michael can you please test and confirm this is the desired behaviour?
Hello Justin, Just thought I'd state right up front that I am now running the latest KDE neon: Operating System: KDE neon 5.20 KDE Plasma Version: 5.20.2 KDE Frameworks Version: 5.75.0 Qt Version: 5.15.0 Konsole Version: 20.08.2 Adding the --hold argument does keep the Konsole window open permanently, but that is not how the prior behavior was when there was no --hold argument, which is the subtler point of my bug report. The prior behavior of: konsole -e echo "foo" && sleep 3 && echo "bar" && sleep 3 && echo "closing" ...was that a new Konsole window would appear, a few lines would slowly print *in the new Konsole window*, and then the new Konsole window would automatically disappear after the new process was done. In contrast, the original bug issue remains when executing: konsole -e echo "foo" && sleep 3 && echo "bar" && sleep 3 && echo "closing" ...in that the new Konsole window appears for an instant and then goes away in a blink of an eye, while the text prints out in the original terminal, where it was not supposed to print.
(In reply to Michael from comment #9) > In contrast, the original bug issue remains when executing: > > konsole -e echo "foo" && sleep 3 && echo "bar" && sleep 3 && echo "closing" As I already tried to say, I think that's rather a "problem" in the application that parses your input (e.g. KF5's desktop file parser). Konsole likely doesn't even see the parts after the first '%%'. That it worked in the past doesn't necessarily mean that it's correct though... I see the same behavior (that you report as "broken") when I enter that line in xterm, even if I replace "konsole" with "xterm": xterm -e echo "foo" && sleep 3 && echo "bar" && sleep 3 && echo "closing" I.e. the new xterm window doesn't even show up, and "bar" and "closing" appear in the original xterm window. IMHO, you need to add quotes as mentioned.
(In reply to Wolfgang Bauer from comment #10) > As I already tried to say, I think that's rather a "problem" in the > application that parses your input (e.g. KF5's desktop file parser). Konsole > likely doesn't even see the parts after the first '%%'. I mean after the first '&&' of course.
Okay, so you're saying I need to enquote the argument string when I launch Konsole. Yes, you're right I should always be enquoting logic as parameters. Fair enough. Now when I do this, I can confirm that it behaves as it used to: konsole -e sh -c 'echo foo && sleep 3 && echo "bar" && sleep 3 && echo "closing"' ...the difference being that it's now necessary to use this idiom: -e sh -c 'fully enquoted string' ^^^^^ But why should I have to add a "sh -c" prefix to my command string? Testing some more, it doesn't work at all when I do this: konsole -e 'echo foo && sleep 3 && echo "bar" && sleep 3 && echo "closing"' According to the Konsole --help documentation, -e is the command to execute. Konsole should be executing my enquoted command as it had done in the past, yet nothing is executed. With this, Konsole appears for an instant just to disappear. The print statements aren't even executed in the originating shell.
Or said another way, what is the rationale for the difference between running Konsole from the GUI and immediately typing commands, and from invoking Konsole from the command line with commands as an argument string? As it is now, they are subtly different in how expect the default running state of Konsole to be. For example, when I run Konsole from the GUI, I don't have to specify which shell that I should be using for the commands I'm about to type in. But when I invoke Konsole from the command line, I have to prepend a "sh -c" to my command string. If there is a good reason to do it this way, I'll sign on for it, although I'd like to see it documented in the konsole --help text so others don't get tripped up by it like me.
I updated the bug name to reflect the actual issue at hand and also the platform and version # too.
On my KDE neon machine, these both behave differently: $ xterm -e 'echo "hello"; sleep 3' $ konsole -e 'echo "hello"; sleep 3' The first does what it's supposed to do, while the second fails. The second needs to be changed to this for it to work: $ konsole -e sh -c 'echo "hello"; sleep 3' Am I missing something for why this should be so?
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
https://bugs.kde.org/show_bug.cgi?id=377412#c12
(In reply to Michael from comment #15) > On my KDE neon machine, these both behave differently: > > $ xterm -e 'echo "hello"; sleep 3' > $ konsole -e 'echo "hello"; sleep 3' > > The first does what it's supposed to do, while the second fails. The second > needs to be changed to this for it to work: > > $ konsole -e sh -c 'echo "hello"; sleep 3' > > Am I missing something for why this should be so? The reason is simple I think: AFAIK "konsole -e xxx" just runs the command directly and passes it the rest of the line as arguments. But the '&&' or ';' are to be parsed by the shell, konsole nor the application it runs cares about them. So to fix this IMHO, "konsole -e" would instead need to run the command via a shell instead, e.g. by prepending "sh -c" itself. No idea if that would be feasible though, I'm not a konsole developer. Btw, that hasn't actually changed recently, I can reproduce the same behavior with konsole 2.14.2 from KDE4...
(In reply to Wolfgang Bauer from comment #18) > But the '&&' or ';' are to be parsed by the shell, konsole nor the > application it runs cares about them. Of course that should read "*neither* konsole nor the application it runs". Sorry,
> The reason is simple I think: > AFAIK "konsole -e xxx" just runs the command directly and passes it the rest of the line as > arguments. > But the '&&' or ';' are to be parsed by the shell, neither konsole nor the > application it runs cares about them. Yes, but I've put the example commands in single quotes so that the arguments are not pre-parsed before the new terminal window receives it: > $ xterm -e 'echo "hello"; sleep 3' > $ konsole -e 'echo "hello"; sleep 3' I still don't see why both of these terminals behave so dramatically differently when executing this. > Btw, that hasn't actually changed recently, I can reproduce the same behavior > with konsole 2.14.2 from KDE4... Okay, must've been further back then.
(In reply to Michael from comment #20) > I still don't see why both of these terminals behave so dramatically > differently when executing this. "xterm -e" probably does send the whole line to sh, while "konsole -e" doesn't.
Updated bug report metadata of Konsole that this still affects, Konsole 20.12.0.