|
Re: FEATURE REQUEST: control over whether child processes block A cmdlet that allows highly granular control over process creation would be
extremely useful. What I do right now is use a function wrapping up
System.Diagnostics.Process that handles it for me. Note that there is a
problem with this for some applications; in many cases, specific processes
actually start child processes and exit, so it may sometimes be necessary to
trace parentage for all new processes as well.
I suggest filing this as a feature request on Connect. For now, here's my
workaround function:
function Start-Process
{
Param(
[string]$Filename,
[string]$ArgumentString = [System.String]::Empty,
[switch]$Wait,
$si = New-Object System.Diagnostics.ProcessStartInfo
$si.Filename = $Filename;
if($ArgumentString){$si.Arguments = $ArgumentString};
#$si.Filename, $si.Arguments;
$ps = [System.Diagnostics.Process]::Start($si);
$ps.WaitForExit();
$ps;
}
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.
"Adam Milazzo" <adammila@microsoft.com> wrote in message
news:Oyc5baavGHA.1512@TK2MSFTNGP04.phx.gbl...
> In unix shells, child processes always block unless you tell them not to.
>
> Eg,
>
> $ xcalc # this blocks and doesn't return until xcalc is done
> $ xcalc & # this does not block
> [1]+ xcalc # it's running in the background and here's the job number
>
> In PoSH, there seems to be no way to control this. In general, it seems
> that programs block if they are console programs, but not if they are GUI
> programs. However, sometimes one would want a GUI program to block, or a
> console program to not block.
>
> I realize it would complicate your "output pipeline", and your single
> $error array.
>
> But I would be perfectly content if you could not "background" a process
> unless the end of the pipe was something other than the console. I would
> also be content if backgrounded processes had no access to $error.
>
> But I don't like having to start up a new instance of PoSH (which takes 9
> seconds on my 3.06ghz machine -- another gripe I have), navigate to the
> same directory, run the command I want, and exit, because the command
> would block my main PoSH window.
>
> I'd much rather be able to do:
>
> build >outfile & # run my build process in the background, write the
> output to 'outfile'
>
> (I know you're using & for something else already, but you get the idea.)
> Then when the build is done, I'll get a notification.
>
> Even more importantly, I'd like to be able to force PoSH to wait for a GUI
> processes to finish.
>
> For instance:
>
> $temp = createTempFile()
> cat "some initial content" >$temp
> openEditor $temp # let the user edit it
> # the user is done, so something with $temp
> rm $temp
>
> I know I could probably simulate some of these things by bypassing PoSH
> and spawning new processes myself, but this is the kind of thing that
> should be handled in the shell.
> |