Adam Milazzo

>> 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.'
More like "You cannot run an arbitrary PS command (ie, a strongly-typed
pipeline containing objects and not just text) asynchronously."

I'm not too concerned about whether I can bring its output buffer to the
foreground. As long as I can redirect the output somewhere that I can
get at it later, I'm content. :-)

> 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.
Yeah, I would want to be able to run any arbitrary PowerShell command
asynchronously.

I think the easiest implementation may involve running each command in a
thread, and the thread always waiting for everything in that command to
complete. If it's in the foreground, it's running in the main thread. If
it's running in the background, it's running in a new thread that's also
blocking on that command. When the thread terminates, it posts a
notification that can be displayed by the main thread. Then job control
would be implemented as manipulation of these threads... suspending,
killing, etc.

>> ... 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.
Yes, I mean GUI programs.

>> % 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.
Hmm, I don't know the details about how telnet shells are implemented.
Is the shell not running on the server?

>> 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.
Well, if it's a problem in any case, then it's a kind of separate issue.
I'm not too concerned about this one...