Bug 217357 - execution of lists fails
Summary: execution of lists fails
Status: RESOLVED FIXED
Alias: None
Product: konsole
Classification: Unclassified
Component: general (show other bugs)
Version: 2.3.1
Platform: unspecified Linux
: NOR wishlist (vote)
Target Milestone: ---
Assignee: Konsole Developer
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-12-04 18:30 UTC by Unknown
Modified: 2011-08-07 23:16 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Unknown 2009-12-04 18:30:52 UTC
Version:           2.3.1 (using 4.3.1 (KDE 4.3.1) "release 6", openSUSE 11.2)
Compiler:          gcc
OS:                Linux (x86_64) release 2.6.31.5-0.1-desktop

konsole -e behaviour seems to have changed since the kde 3.? versions. there is a similar option for xterm which still behaves as expected.

Example:
xterm -e sleep 3 ; echo 1

This will open an xterm window, close it after 3 seconds and then write a 1 on the screen. This is what I would expect to happen.

konsole -e sleep 3 ; echo 1
this will open a konsole window, write the 1 on the screen and close the window after 3 sec.. not as I would expect...
Comment 1 Kurt Hindenburg 2009-12-05 17:35:11 UTC
Yes you are correct.  The issue is that Konsole sees 'konsole -e sleep 3' and then 'echo 1'.  Since there is a ';', Konsole separates the commands.

This would be a bug as -e is suppose to grab everything after the -e
Comment 2 Kurt Hindenburg 2009-12-06 16:52:35 UTC
 I didn't explain it very well in #1.

Konsole async starts the 'sleep 3' and then 'echo 1'

While xterm does them in sync/order.
Comment 3 Unknown 2010-01-16 13:16:27 UTC
I think this should be taken as "Normal" severity rather than "wishlist".
Comment 4 Jekyll Wu 2011-07-18 07:29:03 UTC
I'm sorry, but I think the problem is misunderstood. Or, the problem actually does not exist.

Suppose you type 'whatever-emulator -e sleep 3; echo 1' and press ENTER, it's the SHELL that first take over and divide that into 2 commands: 'whatever-emulator -e sleep 3' and 'echo 1', because ';' is the delimiter among commands in the shell. Then, it run the two commands ONE BY ONE :

1). run 'whatever-emulator -e sleep3'
2). run 'echo 1' ONLY AFTER the first part has finished its job.

So konsole is invoked as 'konsole -e sleep 3' and xterm is invoked as 'xterm -e sleep 3'. The reason of the difference behavior in the report is xterm does not fork and runs in foreground, while konsole forks by default and runs in background. That means 'konsole -e sleep 3 ' will finish immediately and 'echo 1' will be run before the background konsole finish its job.

If 'konsole --nofork -e sleep 3 ; echo 1' is used, the behavior will be the same as the xterm case.

So from the point view of konsole, this is not a bug. Many users just do not konw konsole forks and runs in background by default.
Comment 5 Unknown 2011-07-19 07:59:11 UTC
Well ok, I must say didn't know about konsole forks. However, I also did not fully understand your explanation. What I don't understand is:

If I start my commands in some, lets say, "main" konsole, then by default, as you say, everything invoked here is forked? Not really, e.g.

main> sleep 3 ; echo 1

This sleeps 3 seconds and then prints the 1.

It seems forking is disabled in interactive mode.

If I use a second konsole to sleep, i.e.
main> konsole sleep 3 ; echo 1
then the bahaviour is as discussed.

But, who is forking what here?
The shell running in the main konsole separates the commands. Alright. So it should be the main konsole that forks the second konsole from the echo command, right? Consequently, the option "--nofork" in 
main> konsole --nofork -e sleep 3 ; echo 1
is an option passed to the main konsole and not an option of the second konsole. Strange -- but ok, I hope I understood correctly.

Now the only thing, I think, being left is the misleading explanation of the "-e" option in the konsole help text (version 2.4.3):
"-e command
   Execute command instead of the normal shell.
     Note
       Any arguments after command will be passed to command, not Konsole."

I think at least the note should be removed. Or better, some hint to forking or so should be given. One should mention the different behaviour konsole versus the long established xterm.
Comment 6 Unknown 2011-07-19 08:11:46 UTC
> If I use a second konsole to sleep, i.e.
> main> konsole sleep 3 ; echo 1
> then the bahaviour is as discussed.

I wanted to write:
main> konsole -e sleep 3 ; echo 1

Sry.
Comment 7 Jekyll Wu 2011-07-19 09:19:52 UTC
Let me explain the 'konsole fork itself by default' thing more clearly.

Support now you have one open gnome-terminal or xfce4-terminal as your main terminal (do not use xterm or konsole as your main terminal, just to avoid unnecessary confusion)  

a). if you invoke 'xterm' from main terminal, you will notice that you can't use your main terminal until xterm is closed. 

b). if you invoke 'konsole' from main terminal, you wil notice that you can still use your main terminal while konsole is running.

c). if you invoke 'konsole --nofork' from main terminal, you will notice the same behavior as in the xterm case.

When you invoke 'konsole' from main terminal, the newly created konsole process will automatically fork itself by default. so you will have konsole #1 and konsole #2( a fork of konsole #1). konsole #1 will finish immediately while konsole #2 will do its job.

When you invoke 'konsole --nofork' from main terminal, the newly created konsole process will not fork itself. So you only have konsole #1 and it will do its job.

I hope that explanation is clear and right(correct my misunderstandings, dear developers)

And I agree with your idea about the help text. Forking itself by default is quite unique among terminal emulators.
Comment 8 Unknown 2011-07-19 09:23:46 UTC
OK, so I believe now the second konsole just forks itself off the main konsole
by default. With that I can live. Many thanks for the explanations!

However, could we then just have an improved help text there, please?
Comment 9 Jekyll Wu 2011-07-24 06:44:03 UTC
(In reply to comment #8)
> However, could we then just have an improved help text there, please?


There is another bug report  about the 'run in background by default' behavior and --nofork option, #262169.

You can follow that one or open a new report for improving help text.  This one contains too much noise from me :D
Comment 10 Kurt Hindenburg 2011-07-31 19:17:47 UTC
Git commit 43ff8c48a7a0fd0086845f6aab8ecace51448732 by Kurt Hindenburg.
Committed on 31/07/2011 at 21:11.
Pushed by hindenburg into branch 'master'.

Add --nofork to the --help output.

--nofork is under --help-kde which is often overlooked by users.
Placing a comment under --help should cause less problems for users.
CCBUG: 217357
CCBUG: 262169
CCBUG: 173697

M  +1    -0    src/main.cpp

http://commits.kde.org/konsole/43ff8c48a7a0fd0086845f6aab8ecace51448732