QProcess vs K3Process
ossi at kde.org
Mon May 28 16:48:14 BST 2007
On Mon, May 28, 2007 at 04:47:45PM +0200, Thiago Macieira wrote:
> Oswald Buddenhagen wrote:
> > i'll follow the advice to create a separate KPtyProcess class for
> > it. together with KPty and KPtyDevice (QIODevice wrapper around
> > KPty) it would move to kdelibs/libkpty.
> Ack. This is a good idea. Probably kutils, though, since we already
> have a library for that extra stuff.
uhm, maybe. note that this will pull in libutil and libutempter, though.
> Aside from Konsole/KonsolePart, who else would need this?
see the other thread about this. ;)
there is around a dozen of users in KDE/.
> I.e., if you just want add one variable and remove another, you would do:
> QMap<QString,QString> environment = QProcess::systemEnvironment();
> environment["LD_LIBRARY_PATH"] = "Foo";
> QProcess proc;
yes ... well, for practical reasons a setEnv()-type api is still best.
> >- as noted above, qproc' way of naming the program to execute is
> > different and less convenient. "fixable" in kproc. (*)
> > related ttt (trolltech task): 164361.
> Task id 164361 not found.
oh, the public tracker lags behind. interesting to know. :)
> Do you mean here a setCommandLine()-like call?
> > user-supplied commands might still need being run through a shell.
> > big fat note: on win32, the shell would be cmd, i.e., not posix
> > sh compatible except for the most trivial redirections. (*)
> Which is why setUseShell shouldn't be there. It won't behave the same.
which is why i said "user-supplied". ;)
> If you know your program will run only on Unix, you can use:
> start("sh", QStringList() << "-c" << "mycommand | pipe | whatever");
which is sort of the same, just less convenient ...
> > - qproc does not allow handling only one of stdout/stderr (ttt
> > 131926). kproc could work around this by playing a proxy for the
> > unhandled channel. when qprocess gains the feature, the kproc api
> > would become a trivial wrapper.
> Agreed. This should be done at QProcess level.
do you think i should go for the intermediate solution now? or wait for
qt 4.4 => kde 4.1? as mentioned before, right after the kde 4.0 release
we will need useful .xsession-errors most ...
> >- qproc by default handles stdout/stderr, while k3proc forwards it. imo,
> > the k3proc' "do only what was requested"-approach is much saner, as it
> > does not suppress (error) output (90% of the users *will* forget to
> > disable the unneeded functions). this is "fixable" in kproc, but sort
> > of ugly - i would not do it unless we "condemn" direct qproc usage.
> That might be so, but it's also too late to change QProcess defaults...
yes, but we can override them. but this is inconsistent => problematic,
so i would not do it unless we want to "hide" QProcess entirely - which
isn't a problem, if you ask me.
> >- qproc' startDetached() and execute() are statics.
> > parametrization-wise, this doesn't scale at all. execute() is no
> > problem, as it is trivial. startDetached() *is* a problem - and not
> > fixable in kproc. ttt 131923.
> This would be a nice addition to QProcess's API. However, if you
> startDetached (non-static), your object's state hasn't changed. The
> QIODevice doesn't open. No signals will ever be emitted.
that's sort of right. you'd only get a bool from the function itself and
possibly an error() emission.
> What's the point in having the non-static version?
hey, read more carefully. ;)
to be able to use all the nifty set*() functions on them - environment,
redirections/piping, priorities and whatever else gets added.
simon implemented setting the working directory and obtaining the pid,
so we can use it at all (in krun) - the resulting api is *very* close to
being unaesthetical. see what i mean with "doesn't scale"?
> >- qproc cannot join the (output) channels of multiple processes. not
> > fixable in kproc. ttt 131901.
> > this is from the "get rid of setUseShell" camp. not critical.
> This is possible.
> # shell: foo > bar.txt 2>&1
> QProcess proc;
> proc.setStandardOutputFile( "/bar.txt" );
> Or did I misunderstand you?
yes. i said "multiple processes". we discussed this already at length -
i'm sure you'll remember again after some warmup. :)
> >- qproc does not support process groups/jobs.
> I have to see a use-case for this first.
this is the logical continuation of setStandardOutputProcess().
the example i sent to tt goes like this:
QProcess p1, p2;
whether we actually need system level process groups is another
question - but being able to "kill -TERM -<group leader>" sure would not
Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
Chaos, panic, and disorder - my work here is done.
More information about the kde-core-devel