|
|
|
|
README
|
|
|
|
|
|
|
|
|
|
tdeinit_wrapper, kshell and kwrapper are a programs that
|
|
|
|
|
start programs via tdeinit.
|
|
|
|
|
|
|
|
|
|
E.g. You can make a symbolic link from $KDEDIR/bin/konsole to
|
|
|
|
|
$KDEDIR/bin/tdeinit_wrapper. Typing 'konsole' on the command line
|
|
|
|
|
will then start 'konsole.la' through tdeinit instead.
|
|
|
|
|
|
|
|
|
|
tdeinit_wrapper is the simplest for, it only passes the program
|
|
|
|
|
and arguments to tdeinit, nothing else
|
|
|
|
|
|
|
|
|
|
kshell is usually the best choice, it passes the program,
|
|
|
|
|
arguments, complete environment ( $PATH, etc. ) and current
|
|
|
|
|
working directory to tdeinit
|
|
|
|
|
|
|
|
|
|
kwrapper tries to make the program look like it was actually
|
|
|
|
|
really started directly and not via tdeinit. In addition to
|
|
|
|
|
what kshell does, it also tries to redirect the program
|
|
|
|
|
output to the console from which kwrapper was started, it waits
|
|
|
|
|
for the program started via tdeinit to finish and only after then
|
|
|
|
|
it exits ( it doesn't return its return value though ), and
|
|
|
|
|
it also passes most signals it gets to the process of the started
|
|
|
|
|
program ( thus allowing you to break it using Ctrl+C or stopping
|
|
|
|
|
it using Ctrl+Z ). The drawbacks of this are that you'll have one
|
|
|
|
|
more process running, and also the signal passing and output
|
|
|
|
|
redirection may not work 100% reliably
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
TODO
|
|
|
|
|
====
|
|
|
|
|
|
|
|
|
|
* There is no portable way to read out the complete environment and
|
|
|
|
|
pass it to tdeinit. - tdeinit should probably unset every
|
|
|
|
|
variable that's not set in the environment it gets from kshell or
|
|
|
|
|
kwrapper
|
|
|
|
|
* stdout/stderr of the started application goes to the console where
|
|
|
|
|
tdeinit was started. - done, I hope it's ok
|
