QProcess vs K3Process

Oswald Buddenhagen ossi at kde.org
Tue May 29 12:08:40 BST 2007

On Mon, May 28, 2007 at 10:24:16PM +0200, Thiago Macieira wrote:
> Oswald Buddenhagen wrote:
> >> 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.
> I don't think it's a problem for libkutils. It's very far down the chain. 
> Not many things use that library anyways.
i'm no particular fan of this "dumping ground" approach, but i have not
strong opinion, either.

> >> 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 ...
> Indeed, but it's the price to pay for using a shell. At least in this
> case the user is under no impression that his code is portable. We're
> forcing him to realise that.
experience shows that slight inconvenience does not have much educative
effect. it *does* however lead to code that not only does the wrong
thing, but also in a wrong way.

> I'd say setUseShell should stay away.
consequently i disagree.
take this example: end-user can configure PrintCommand in foobarrc. it
makes plain no sense not to use a shell; the command is expected to be
in the end it is a documentation matter - say which uses are wrong and
which alternatives exist.

> >> >- 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. :)
> Then it isn't the bug report you mentioned.
well, in fact it is, it just got mangled on the way from the issue
tracker to the task tracker. :}
i attached the complete mail.

> If you mean:
>   (foo; bar | baz) 2>/bar.txt
> kind of stuff, I'm still a bit skeptical. When I added the piping between 
> process feature in QProcess last year, I discussed this with you and I 
> thought it was far too specific to warrant support.
this is just thaking things to the next logical level. you agreed that
we don't want to drop stderr out of .xsession-errors. now suppose, the
programmer wants to collect the stderr to show it in a dialog. to
guarantee that order is preserved, the channels *have* to be merged at
the os level. in can come up with more cases, but i'm in a hurry. ;)

> Especially if it's complex to implement.
as i speculated back then, it will need the Channel objects being
QShared instances (or something to that effect). i don't think it will
be *too* complex.

> >> >- 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. :)
> That sounds like a nice API, but why would we want it in Qt or even in 
> KDE Libs?
> I understand what it would do, but what's the actual use-case for this in 
> KDE?
the grouping per se is just convenience. you don't want to build a pipe
from three processes and start every one, check the errors, handle
signals, etc. separately.
for the os level thing i have a much weaker case. unless somebody wants
to implement a shell with qt, no app will need it. however, it is
potentially useful for a user - it would be easier to kill off a stuck

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 mailing list