QProcess vs K3Process

[Oswald Buddenhagen]

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";
>   environment.remove("LD_PRELOAD");
>   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?
> 
yes.

> >  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" );
>  proc.setProcessChannelMode(QProcess::MergedChannels);

> 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;
p1.setProgram("ls");
p2.setProgram("less");
p1.setProcessGroupLeader();
p2.joinProcessGroup(&p1);
p1.setStandardOutputProcess(&p2);
p1.start();

whether we actually need system level process groups is another
question - but being able to "kill -TERM -<group leader>" sure would not
hurt. :)

-- 
Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
--
Chaos, panic, and disorder - my work here is done.