Some comments inline. This gets messy because of how Windows processes
generally work, unfortunately. Your points about what we really need are
spot on, but you're being imprecise about a couple of things.
Your points towards the end do get into some important low-level issues that
_do_ need to be addressed. Some of them are on the shopping list, but
couldn't be done in the timeframe for version 1.
"Adam Milazzo" <adamm@san.rr.com> wrote in message
news:OhV8uzjvGHA.3912@TK2MSFTNGP03.phx.gbl...
> Alex K. Angelopoulos [MVP] wrote:
>> Note that the returned process is still usable for details, and if you do
>> have processes descended from the one you invoked, you can check existing
>> processes to see if they are descended from that process id.
> Cool. Yeah, workarounds are possible, and you could even extend this
> function to add some kind of job control, but the problems with it are:
>
> 1) No support for PS pipelining and CmdLets.
I think I see what you're after, but as you phrased it this isn't true. You
can get exit status back if you are waiting for termination, and if you are
running the process in a separate thread, you can check it from PowerShell.
Is the following a decent paraphrase of what you're talking about?
' you cannot start a process asynchronously, capturing its output, and bring
its output buffer to the foreground when you want from a PowerShell prompt.'
Not only is that very true, but the same problem exists for PowerShell
cmdlets/functions/scripts in the initial release: you can't asynchronously
execute a same-console PowerShell command. This is a significant issue that
needs to be handled. There's a long-term plan involving runspaces which
should also help with some of .NET's own un-scriptish versioning issues.
> ... It only works for Win32 programs, and they can't participate in PS
> pipelines. So you can't easily do:
You mean GUI subsystem programs, I think - console-based programs are
generally Win32 as well.
> % longRunningTask | my-filter >output & # run in background
> [1]+ longRunningTask (running)
right. And even though you can do async execution if you're willing to
forego the output access, you're toast if you're trying to work via a telnet
shell since the process would detach from the window.
> 2) Only works if you know the path to the executable name. So it won't
> work if the user has defined a PS function to open, say, his favorite
> editor:
>
> % editor file.txt # invoke user's favorite editor
> % StartProcess editor # don't know the exact path...
>
> It works fine when 'editor' is a program, but not if the user defines it
> with an alias or a function.
Unfortunately true, because this isn't a direct invocation. You can indeed
use functions, variables, and aliases here, but they would all need to
evaluate to appropriate elements, which kind of reduces the ease of use,
since you can't mix the commandline arguments into this - process start here
doesn't allow passing a complete command-line. :|
> 3) You have to construct the arguments string yourself, requiring escaping
> of arguments, etc. Not an impossible task, but more complicated than you
> might think to get perfectly right. :-) It'd be nice to have shell
> support here...
And this problem will still exist with a background invocation operator,
unfortunately - although the applications that will have problems are
limited. Since PS parses every command line and then re-assembles it for
external executables, an unescaped bare argument in this form:
-<x>:<value>
is reassembled as:
-<x>: <value>
This shouldn't be a problem for most POSIX apps I think, but ones that use
homegrown parsers can be in trouble.
> The third could be fixed with a support function to do escaping, the
> second can be worked around by using variables instead of functions (like
> they did in CMD.exe -- StartProcess $EDITOR), but the first really needs
> shell support.
>
> That said, creating processes manually does help a little bit.