QProcess vs K3Process

[Oswald Buddenhagen]

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
platform-specific.
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
pipe.

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