Bug 119105 - wish for --nofork in kstart
Summary: wish for --nofork in kstart
Status: RESOLVED INTENTIONAL
Alias: None
Product: kstart
Classification: Plasma
Component: general (show other bugs)
Version: unspecified
Platform: Mandriva RPMs Linux
: NOR wishlist
Target Milestone: ---
Assignee: Lubos Lunak
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-12-28 11:16 UTC by Richard Neill
Modified: 2021-06-29 09:31 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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.]