QProcess vs K3Process

[Thiago Macieira]

Oswald Buddenhagen wrote:
>> >> 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.

Maybe a separate class then? KShellProcess or something similar.

You could even support perl-like process opening:
	start("something |");
	start("| something");

>> 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. ;)

Ok, I see. You want
	foo | bar >/dev/null

And you want to collect stderr from both processes, merged. I see the 
use-case, but I would argue that it's in fact better to collect them 
separately. That way, if an error is reported, the application can 
identify which process did it.

>> >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.

Start every one? Yes, I think you want that. And it isn't difficult 
anyways, nor is there a particular order in which they must happen. The 
pipes are created when first needed and the remote end is open when the 
application starts (either in the parent or in the sibling process).

Check errors, as I said above, it's probably better to detect which object 
had errors. But you could just connect the signals to the same slots and 
ignore QObject::sender().

>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.

Why would a pipe get stuck under normal operating conditions? Besides, if 
you kill the writing end of a pipe, the reading end gets a SIGPIPE. Or 
EOF.

No, I am not convinced by process groups. For more complex piping 
mechanisms, maybe. Maybe someone has a valid need for something like:

shell: (A | B) 2>&1 >/dev/null | C
	A ----stdout---> B --stdout--> /dev/null
	  \		  \--stderr--\
	   \-----------------stderr-------> C

Or, worse, not possible with shell:
	A ----stdout---> B --stdout------> C
	  \		  \--stderr--\
	   \-----------------stderr------> D

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070529/9d52112c/attachment.sig>