http://bugs.winehq.org/show_bug.cgi?id=10192
Jason Edmeades us@edmeades.me.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED
--- Comment #4 from Jason Edmeades us@edmeades.me.uk 2007-11-18 14:04:48 --- Sorry - due to a bereavement followed by a vacation, I havent got to it yet.. Back now so hopefully soon (give me a few days to catch up).
Unfortunately its not easy to fix, but to do it properly will remove part of a hack which isnt nice anyway: - Originally, the commandline was null terminated at the first >. < or | character, and everything before it was the command, and everything after it was then special cased into pipe command or filename. This was very wrong in lots of respects and failed to handle most cases other than the one it worked for. The pipe support is also hacked in (wcmd_pipe) whereas it really should be handleable by the mainline code.
- Now, when parsing a line we split the input into a command string and redirects. Currently, the pipe is put into the redirects which is where it all goes badly wrong (The wcmd_pipe routine assumes the command string contains the command whereas it no longer does)
- The 'right' fix is to extend the support for && to also support | (and || plus & which also work and are unsupported) - ie split the pipe bit of the input into a new command chained off the previous one, with flags saying what its used for
This will also resolve problems like "mycommand 2>error.log | mypipe 2>error2.log" which currently fail badly
Out of interest whats the exact command which fails in the kde4 stuff - I'll ensure I use it as a testcase.