QProcess vs K3Process

[Thiago Macieira]

Oswald Buddenhagen wrote:
>this is a list of missing [KQ]Process features and differences between
>qproc and k3proc. please comment on the desirability of the particular
>points.
>
>- qproc has no pty support. that's fine, it is doable in kproc. i guess
>  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. Aside from Konsole/KonsolePart, who else 
would need this?

>- qproc does not allow setting individual env vars, only the entire
>  environment. pretty inconvenient, if you ask me. can be easily
>  implemented in kproc.

You can do that by accessing QProcess::systemEnvironment. It would be 
nicer if this were a QMap<QString,QString> though. Adding is easy, but 
removing an entry isn't:

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

>- qproc does not support setting priorities.
>  win32 has only scheduling classes, while unix has (fewer) classes
>  and the nice level. this needs some thinking.
>  should be possible in kproc, but pretty ugly. (*)
>  preparing mail to qt-bugs.

Agreed that this needs some thinking.

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

Do you mean here a setCommandLine()-like call?

Unfortunately, I don't see a pattern in Qt right now. QProcess is a 
QIODevice, but its two siblings have different paradigms.

See:
	QTcpSocket socket;
	socket.connectToHost(hostname, port);
not:
	QTcpSocket socket;
	socket.setAddress(hostname, port);
	socket.connectToHost();

However:
	QFile file;
	file.setFileName(filename);
	file.open();

>- qproc has no setUseShell. generally, shell usage should be eliminated
>  as far as possible (usually it is used for constructing hard-coded
>  pipes, for which qproc has a better solution now - for most parts).
>  however, 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.

If you know your program will run only on Unix, you can use:
   start("sh", QStringList() << "-c" << "mycommand | pipe | whatever");

>- 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. that's Not Nice (performance, reliability), but qproc does
>  this on win32 anyway (i have no idea why). when qprocess gains the
>  feature, the kproc api would become a trivial wrapper.

Agreed. This should be done at QProcess level.

We do want to leave stderr connected to .xsession-errors.

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

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

What's the point in having the non-static version?

>- qproc has no detach(). not fixable in kproc. ttt 131933.
>  there is exactly one user in kdelibs: kio/kfile/kfilesharedialog.cpp.
>  please verify that it is legitimate, i.e. that the child must be able
>  to outlive the parent and that it cannot be started detached in the
>  first place. hi dfaure ;)

That's a call to kdesu and the caller wants to know if the child exited. 
But if the caller exits its code, it won't care about the child and will 
leave it running.

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

>- qproc does not support process groups/jobs.
>  also from the "get rid of setUseShell" camp. primarily meant as a
>  convenience feature - it sucks to build a pipe from three processes
>  and having to deal with every one separately. this can be built as a
>  separate class KProcessGroup; the os-level part which is not fixable
>  in kproc is sort of optional. mail to qt-bugs in preparation.

I have to see a use-case for this first.

-- 
  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/20070528/2e4e571c/attachment.sig>