Vista - BUG? - inconsistent blocking of child processes

I had a batch file, e.bat, which I used in cmd.exe

The batch file contained one line:
@start "" %editor% %*

If I have some script code do this:

e foo
echo done

or this:

& { e foo; echo done }

The invocation of the editor will not block, and "done" will be printed
immediately.

That is not unexpected. However, if I do the following:

$editor = @{};
$editor = $editor | add-member ScriptProperty Edit { e foo; echo
done } -passthru
$editor.Edit # this DOES block when executing 'e', and 'done' will not be
printed until the editor is closed

However if I change 'e' to a function:

function e { myEditor $args }

Then $editor.Edit doesn't block.

This is inconsistent, and I think some bug lies here.

What editor are you using? Does it have a GUI or does it use the console?


"Adam Milazzo" <adammila@microsoft.com> wrote in message
news:OnvYJGavGHA.1772@TK2MSFTNGP06.phx.gbl...
>I had a batch file, e.bat, which I used in cmd.exe
>
> The batch file contained one line:
> @start "" %editor% %*
>
> If I have some script code do this:
>
> e foo
> echo done
>
> or this:
>
> & { e foo; echo done }
>
> The invocation of the editor will not block, and "done" will be printed
> immediately.
>
> That is not unexpected. However, if I do the following:
>
> $editor = @{};
> $editor = $editor | add-member ScriptProperty Edit { e foo; echo
> done } -passthru
> $editor.Edit # this DOES block when executing 'e', and 'done' will not be
> printed until the editor is closed
>
> However if I change 'e' to a function:
>
> function e { myEditor $args }
>
> Then $editor.Edit doesn't block.
>
> This is inconsistent, and I think some bug lies here.
>

I am using Vim (gvim.exe). It has a GUI and does not write to the console.

"Marcel J. Ortiz [MSFT]" <mosoto@online.microsoft.com> wrote in message
news:eENvlcavGHA.4460@TK2MSFTNGP05.phx.gbl...
> What editor are you using? Does it have a GUI or does it use the console?
>
>
> "Adam Milazzo" <adammila@microsoft.com> wrote in message
> news:OnvYJGavGHA.1772@TK2MSFTNGP06.phx.gbl...
>>I had a batch file, e.bat, which I used in cmd.exe
>>
>> The batch file contained one line:
>> @start "" %editor% %*
>>
>> If I have some script code do this:
>>
>> e foo
>> echo done
>>
>> or this:
>>
>> & { e foo; echo done }
>>
>> The invocation of the editor will not block, and "done" will be printed
>> immediately.
>>
>> That is not unexpected. However, if I do the following:
>>
>> $editor = @{};
>> $editor = $editor | add-member ScriptProperty Edit { e foo; echo
>> done } -passthru
>> $editor.Edit # this DOES block when executing 'e', and 'done' will not
>> be printed until the editor is closed
>>
>> However if I change 'e' to a function:
>>
>> function e { myEditor $args }
>>
>> Then $editor.Edit doesn't block.
>>
>> This is inconsistent, and I think some bug lies here.
>>
>
>

Marcel,

You _may_ vaguely remember that during beta I had asked about whether anyone
had ideas on a good way to determine whether an application used the console
subsystem, a GUI, or automatically ran as a service. You were one of the
people who responded with ideas on it, I think.

Being able to guess whether a process would be likely to detach from the
console was one of my secondary reasons for that question, since GUI
processes always do so in PS.

"Adam Milazzo" <adammila@microsoft.com> wrote in message
news:eiyFyjavGHA.4576@TK2MSFTNGP03.phx.gbl...
>I am using Vim (gvim.exe). It has a GUI and does not write to the console.
>
> "Marcel J. Ortiz [MSFT]" <mosoto@online.microsoft.com> wrote in message
> news:eENvlcavGHA.4460@TK2MSFTNGP05.phx.gbl...
>> What editor are you using? Does it have a GUI or does it use the
>> console?
>>
>>
>> "Adam Milazzo" <adammila@microsoft.com> wrote in message
>> news:OnvYJGavGHA.1772@TK2MSFTNGP06.phx.gbl...
>>>I had a batch file, e.bat, which I used in cmd.exe
>>>
>>> The batch file contained one line:
>>> @start "" %editor% %*
>>>
>>> If I have some script code do this:
>>>
>>> e foo
>>> echo done
>>>
>>> or this:
>>>
>>> & { e foo; echo done }
>>>
>>> The invocation of the editor will not block, and "done" will be printed
>>> immediately.
>>>
>>> That is not unexpected. However, if I do the following:
>>>
>>> $editor = @{};
>>> $editor = $editor | add-member ScriptProperty Edit { e foo; echo
>>> done } -passthru
>>> $editor.Edit # this DOES block when executing 'e', and 'done' will not
>>> be printed until the editor is closed
>>>
>>> However if I change 'e' to a function:
>>>
>>> function e { myEditor $args }
>>>
>>> Then $editor.Edit doesn't block.
>>>
>>> This is inconsistent, and I think some bug lies here.
>>>
>>
>>
>
>

Alex K. Angelopoulos [MVP] wrote:
> Marcel,
>
> You _may_ vaguely remember that during beta I had asked about whether anyone
> had ideas on a good way to determine whether an application used the console
> subsystem, a GUI, or automatically ran as a service. You were one of the
> people who responded with ideas on it, I think.
Hmm, I don't think so. I only started using PoSH 2 weeks ago, and only
started posting to the newsgroup yesterday. :-)

> Being able to guess whether a process would be likely to detach from the
> console was one of my secondary reasons for that question, since GUI
> processes always do so in PS.
My idea is not to guess, but to always wait for processes to finish by
default, but allow a user to run a process "in the background", which
never waits for it to finish. This way you always know whether a process
will block or not, and you can write scripts that work consistently
regardless of what kind of executable the user's favorite editor is, say.

Essentially, I'm basing this on the "job control" model that exists in
the bash shell, which is a very nice system. For instance:

% editor $file # run the user's favorite editor, and block
% editor $file & # run the user's favorite editor in the background
[1]+ editor c:\foo.txt (running) # and here's the job ID

# run a long process in the background and send the results to 'output'
% someLongRunningProcess >output &
[2]+ someLongRunningProcess (running)

"Adam Milazzo" <adamm@san.rr.com> wrote in message
news:OR%232G7jvGHA.4384@TK2MSFTNGP04.phx.gbl...
> Alex K. Angelopoulos [MVP] wrote:
>> Marcel,
>>
>> You _may_ vaguely remember that during beta I had asked about whether
>> anyone had ideas on a good way to determine whether an application used
>> the console subsystem, a GUI, or automatically ran as a service. You were
>> one of the people who responded with ideas on it, I think.
> Hmm, I don't think so. I only started using PoSH 2 weeks ago, and only
> started posting to the newsgroup yesterday. :-)

But _Marcel_ has.

If the last command in a pipeline is a Win32 GUI executable and the command
is not redirected, then the command will run without blocking. If the
command occurs in the middle of a pipeline or is otherwise redirected, then
we will block until that command is complete. This allows you to use editors
in the middle of a pipeline. It's essentially the same behaviour that
cmd.exe has. Now "redirected" is a bit tricky to calculate:
dir | notepad.exe # not redirected, doesn't block
$a = dir| notepad.exe # redirected so it blocks
function el { dir| notepad.exe }
el # not redirected, doesn't
block
$a = el # redirected, block
and so on

Of course, cmd.exe doesn't have the ability to add properties to an object
so the add-member example has no parallel in cmd.exe. In theory, synthetic
members (script properties and methods) are always "redirected" - we're
always capturing the output of the command so launching an editor from a
script method or property should block. The fact that when you add the extra
layer of function call, it doesn't block indicates that there is a bug in
the logic that figures out when something is redirected or not.

As for job control, we're reserved the trailing & so we can add some level
of job control in a future release although what form that takes remains to
be seen. You can use the Process class to work around these issues if
necessary. For example, you could start notepad by doing
$pid = [diagnostics.process]::Start("notepad.exe")

-bruce

--
Bruce Payette [MSFT]
Windows PowerShell Technical Lead
Microsoft Corporation
This posting is provided "AS IS" with no warranties, and confers no rights.
Visit the Windows PowerShell Team blog at:
http://blogs.msdn.com/PowerShell
Visit the Windows PowerShell ScriptCenter at:
http://www.microsoft.com/technet/scr.../hubs/msh.mspx


"Adam Milazzo" <adammila@microsoft.com> wrote in message
news:OnvYJGavGHA.1772@TK2MSFTNGP06.phx.gbl...
>I had a batch file, e.bat, which I used in cmd.exe
>
> The batch file contained one line:
> @start "" %editor% %*
>
> If I have some script code do this:
>
> e foo
> echo done
>
> or this:
>
> & { e foo; echo done }
>
> The invocation of the editor will not block, and "done" will be printed
> immediately.
>
> That is not unexpected. However, if I do the following:
>
> $editor = @{};
> $editor = $editor | add-member ScriptProperty Edit { e foo; echo
> done } -passthru
> $editor.Edit # this DOES block when executing 'e', and 'done' will not be
> printed until the editor is closed
>
> However if I change 'e' to a function:
>
> function e { myEditor $args }
>
> Then $editor.Edit doesn't block.
>
> This is inconsistent, and I think some bug lies here.
>

Interesting... thanks for the informative reply.

Bruce Payette [MSFT] wrote:
> If the last command in a pipeline is a Win32 GUI executable and the command
> is not redirected, then the command will run without blocking. If the
> command occurs in the middle of a pipeline or is otherwise redirected, then
> we will block until that command is complete. This allows you to use editors
> in the middle of a pipeline. It's essentially the same behaviour that
> cmd.exe has. Now "redirected" is a bit tricky to calculate:
> dir | notepad.exe # not redirected, doesn't block
> $a = dir| notepad.exe # redirected so it blocks
> function el { dir| notepad.exe }
> el # not redirected, doesn't
> block
> $a = el # redirected, block
> and so on
>
> Of course, cmd.exe doesn't have the ability to add properties to an object
> so the add-member example has no parallel in cmd.exe. In theory, synthetic
> members (script properties and methods) are always "redirected" - we're
> always capturing the output of the command so launching an editor from a
> script method or property should block. The fact that when you add the extra
> layer of function call, it doesn't block indicates that there is a bug in
> the logic that figures out when something is redirected or not.
>
> As for job control, we're reserved the trailing & so we can add some level
> of job control in a future release although what form that takes remains to
> be seen. You can use the Process class to work around these issues if
> necessary. For example, you could start notepad by doing
> $pid = [diagnostics.process]::Start("notepad.exe")
>
> -bruce
>

> If the last command in a pipeline is a Win32 GUI executable and the command
> is not redirected, then the command will run without blocking. If the
> command occurs in the middle of a pipeline or is otherwise redirected, then
> we will block until that command is complete. This allows you to use editors
> in the middle of a pipeline. It's essentially the same behaviour that
> cmd.exe has. Now "redirected" is a bit tricky to calculate:
> dir | notepad.exe # not redirected, doesn't block
> $a = dir| notepad.exe # redirected so it blocks
> function el { dir| notepad.exe }
> el # not redirected, doesn't
> block
> $a = el # redirected, block
> and so on
>
> Of course, cmd.exe doesn't have the ability to add properties to an object
> so the add-member example has no parallel in cmd.exe. In theory, synthetic
> members (script properties and methods) are always "redirected" - we're
> always capturing the output of the command so launching an editor from a
> script method or property should block. The fact that when you add the extra
> layer of function call, it doesn't block indicates that there is a bug in
> the logic that figures out when something is redirected or not.
>
> As for job control, we're reserved the trailing & so we can add some level
> of job control in a future release although what form that takes remains to
> be seen. You can use the Process class to work around these issues if
> necessary. For example, you could start notepad by doing
> $pid = [diagnostics.process]::Start("notepad.exe")
>
> -bruce
>

Bruce Payette [MSFT] wrote:
> If the last command in a pipeline is a Win32 GUI executable and the command
> is not redirected, then the command will run without blocking. If the
> command occurs in the middle of a pipeline or is otherwise redirected, then
> we will block until that command is complete. This allows you to use editors
> in the middle of a pipeline. It's essentially the same behaviour that
> cmd.exe has. Now "redirected" is a bit tricky to calculate:
> dir | notepad.exe # not redirected, doesn't block
> $a = dir| notepad.exe # redirected so it blocks
> function el { dir| notepad.exe }
> el # not redirected, doesn't
> block
> $a = el # redirected, block
> and so on

It seems that these don't work, though. None of them block.

$a = dir | notepad.exe # this actually doesn't block