Bug 119105

Summary:	wish for --nofork in kstart
Product:	[Unmaintained] kstart	Reporter:	Richard Neill <kde>
Component:	general	Assignee:	Lubos Lunak <l.lunak>
Status:	RESOLVED INTENTIONAL
Severity:	wishlist	CC:	kde
Priority:	NOR
Version First Reported In:	unspecified
Target Milestone:	---
Platform:	Mandriva RPMs
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

Description Richard Neill 2005-12-28 11:16:49 UTC

Version:            (using KDE KDE 3.5.0)
Installed from:    Mandriva RPMs
OS:                Linux

It would be really nice to have a --nofork option to kstart. Thus, instead of starting the application in the background and returning to the prompt, the application would remain in the foreground. eg:

  kstart --fullscreen --nofork  vncviewer [ARGS]

At the moment, kstart returns to the prompt immediately, and with exit code 0. So 
1) There is no way to Ctrl-C the started application.
2) There is also no way to discover the PID of the application which was launched. 
3) We also can't wait until the application exits (eg to run some further command)
4) We can't discover the exit code of the application.



A use of this might be (pseudocode):
----------------
#!/bin/bash
Start SSH tunnel.
Start second SSH tunnel within first tunnel (to go through multiple nested firewalls)
Start vncviewer over ssh
Wait for vncviewer to close
Stop the SSH tunnels.
exit with exit value of vncviewer.
---------------

A possible alternative would be for kstart to exit with exit-code = PID of application, or to set $! (like bash does for commands launched with &)

Comment 1 Lubos Lunak 2006-01-04 17:36:16 UTC

It might be simpler to use window-specific settings (Alt+F3/Advanced/...) and launch vncviewer directly, perhaps with --class argument to have a distinct window class to be able to have a rule only for this specific case.

Comment 2 Richard Neill 2006-01-04 18:05:20 UTC

Re #1: Thanks for the workaround. But I still think my proposal would be useful, because:
  * Wanting kstart not to fork must be quite a common condition
and
  * kstart is already quite powerful, and easy to use. It's the logical place
    to put it.


[Incidentally, another possible switch might be --wait-for-window. This would
This would delay the return of kstart until the application had finished starting up. eg "kstart --wait-for-window oowriter" would only return to the prompt after oowriter had loaded (which takes about 40 seconds on my system!)
However, I think it might be hard to do, and it would be only occasionally useful.]