KProcess overhaul [PATCH]

[Oswald Buddenhagen]

On Mon, Apr 17, 2006 at 07:03:43PM +0200, Ralf Habacker wrote:
> Oswald Buddenhagen schrieb:
> >On Mon, Apr 17, 2006 at 01:57:25PM +0200, Ralf Habacker wrote:
> >>8-10 not implemented (on windows not required)
> >>
> >this is simply not true. only pty support is not needed; redirections
> >in general *are* needed, now even more than before, as we want
> >portability, so we can't simply use the unix shell syntax anymore.
> >  
> Not sure, what you mean exactly here and where this support is used or
> required in the kde sources. Can you give an example ?
> 
i can't come up with an example where i can assure you that it is
meaningful for windows, but if you grep for setUseShell you will find
many redirections for unix. :)

> >>new use cases 11. run a process using a command line shell
> >>
> >>    
> >it should be noted that this bears *considerable* portability
> >problems.
> >  
> yes, which will still exists in some area, where the unix command have
> other names as on windows.
>
yes. after all, i don't think we'll write too many cross-platform shell
commands ...

> >the quoting rules are *totally* different 
> How are they different ?
>
really, read the man pages.

> >the only thing the shell should be used for are user-supplied commands.
> >for internal stuff, either the code should be rewritten not to use a
> >shell (as stated before, the majority of the cases is a poor man's
> >workaround for the lack of redirection support in kprocess), or, if it
> >is not hard-coded (like in .desktop files), it should be written in unix
> >shell syntax and interpreted internally - i intend to put a *simple*
> >shell execution semantics interpreter into KShell.
> >  
> Agreed, but KProcess need an interface for executing a shell. It is okay 
> as it is ?
>
i don't have objections.
well, in fact i hoped to go more into the direction of set<SomeMode>
functions and one async exec() with very few options, but unfortunately
qt went exactly the opposite direction, so for consistency we should do
the same. oh, well.

> Additional, do you have an example for this ?
> 
?

> >1) on unix, -c is required (where it is /c on windoze). remember that
> >everything in windows that is not fundametally new (is there something
> >like that at all?) is based on unix concepts. :-P
> >btw, you botched the if-else cascade. 
> which comes from the old KProcess code. If other shells beside /bin/sh 
> aren't required, this code could be reduced very much.
> 
re-read the code and the message. c is mean. ;)

> >but there's no reason for
> >shellOptions anyway, as it is required to be consistent among shells.
> >  
> QProcess::start()'s or QProcess:execute()'s first parameter must be an 
> executable without any parameters, otherwise it couldn't be located in 
> the path variable.
> This require to save parameters elsewhere in this case shellOptions. Is 
> this okay for you ?
>
on unix it is always shell -c command, on windows shell /c command - so
why do you want to save it in a variable?

> >2) you botched the command composition. it is 
> >"shell -c <all-arguments-concatenated>", not "shell -c <arg> <arg> ...".
> >on windows that does not matter, as everything is more or less simply
> >concatenated into one string anyway, but on unix it does.
> >  
> I don't know how to implement this on unix.
>
you could simly read the old code.
honestly, you are scaring me by playing with this stuff. get yourself *a
bit* into the topic first, for *all* relevant platforms.

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