Vista Forums - View Single Post - FEATURE REQUEST: control over whether child processes block

08-12-2006

Alex K. Angelopoulos [MVP] wrote:
> 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:
> [snip]
> 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. It only works for Win32
programs, and they can't participate in PS pipelines. So you can't
easily do:

% longRunningTask | my-filter >output & # run in background
[1]+ longRunningTask (running)

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.

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...

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.

08-12-2006	#5 (permalink)
Adam Milazzo n/a posts	Re: FEATURE REQUEST: control over whether child processes block Alex K. Angelopoulos [MVP] wrote: > 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: > [snip] > 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. It only works for Win32 programs, and they can't participate in PS pipelines. So you can't easily do: % longRunningTask \| my-filter >output & # run in background [1]+ longRunningTask (running) 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. 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... 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.
My System Specs