"Adam Milazzo" <adamm@san.rr.com> wrote in message
news:%231KuylpvGHA.4512@TK2MSFTNGP05.phx.gbl...
> 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. :-)
OK. This is coming - I don't know when, but runspaces are definitely on the
road map, and redirection in some form _will_ work. Theoretically, this is
already possible, although in a rather ugly fashion: you would have to
serialize output using Export-Csv or Export-CliXml, then invoke a PowerShell
instance that imports the data, runs a command, then exports it when done,
and your main instance can check the process periodically to see if it has
exited yet. This is of course an ugly approach, suitable only as a stopgap.
(snipping bits I don't know about)
>> 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?
It is. What I mean is that unlike an on-console session, you wouldn't be
able to "see" a process that has detached - it would be running on the
server, but in a separate hidden window not accessible from the client and
which the telnet session on the server has no means to connect to. so you
won't see anything going on in that window.