Vista - Puzzled with 'continue'

The script below outputs nothing:

# Test1.ps1
1..10 | % {
if ($_ % 2) {
continue
}
$_
}
'Test1 end'

It looks like 'continue' terminates the script. Moreover, Test2.ps1 which
calls Test1.ps also outputs nothing:

# Test2.ps1
Test1.ps1
'Test2 end'

Thus, it looks like 'continue' in Test1.ps1 also terminates Test2.ps1. What
is the rationale of this 'continue' effect?

P.S. Tracing confirms that 'continue' is the last executed statement:

0> Set-PSDebug -trace 2
0> Test2
DEBUG: 1+ Test2
DEBUG: ! CALL script 'Test2.ps1'
DEBUG: 1+ Test1.ps1
DEBUG: ! CALL script 'Test1.ps1'
DEBUG: 1+ 1..10 | % {
DEBUG: 2+ if ($_ % 2) {
DEBUG: 3+ continue

--
Thanks,
Roman

makes sense to me, continue will try to find the looping scope above
the one that it is in and then have it continue of the next
interation.. here there is no scope above it that is looping, so it
basically breaks out and exits.. we look at this and thik why isnt it
breaking out of the foreach, %, but really the foreach is a cmdlet, and
this is the pipeline.. the continue keyword i believe is for breaking
out of looping language contructs and continueing, not continueing on
the next pipeline item.

try the following ( i can't experiment with it myself as i'm on vista
right now without PS)

#test2.ps1
foreach($a in 1..5) {
test1.ps1
$a
}

here i presume that the continue inside the test1.ps1 should break out
the the foreach keyword loop (in contrast to foreach-object cmdlet) and
it should continue.

"klumsy@gmail.com" wrote:
> ...

Perhaps your guesses are correct, at least your script worked as you expected.

Meanwhile, in my case there is no looping. If looping is not found then
'continue' probably should rise an error, because more likely it is a user
bug. Or is it a weird legal way to exit?

--
Thanks,
Roman

Replaying to <klumsy@gmail.com> I said that it would be perhaps more natural
if 'continue' fails when looping is not found.

But it does not fail in the examples Test1.ps1 and Test2.ps1.

But it does fail in the example below and with very misleading message:

CODE:

gci c:\ | .{process{ $_; continue }}

OUTPUT:

Directory: Microsoft.PowerShell.Core\FileSystem::C:\

Mode LastWriteTime Length Name
---- ------------- ------ ----
d---- 23/04/2006 22:53 xxx
Get-ChildItem : System error.
At line:1 char:4
+ gci <<<< c:\ | .{process{ $_; continue }}

Note the error message and where an error is designated. In the real code it
was not so easy to find that 'continue' caused an error.

So,
*) why does 'continue' fails here and does not in Test1.ps1 and Test2.ps1?
*) what about this strange error message?

--
Thanks,
Roman

I can confirm this issue as well. I think the problem is that when 'continue'
is called within gci (because the 'loop' is probably to be found somewhere in
there), the Cmdlet does not handle this situation correctly. I did a quickt
test on this and it seems that continue is supposed to act between different
steps of the pipeline (and sometimes even works as expected!):

0,1,2,3,4,5 | .{process{$_;continue}}
0

$(for($i=0;$i -lt 5;$i++){$i}) | .{process{$_;continue}}
0

$(foreach ($i in (0,1,2,3,4,5)) {$i}) | .{process{$_;continue}}
0

Get-Process | .{process{$_;continue}}

Handles NPM(K) PM(K) WS(K) VM(M) CPU(s) Id ProcessName
------- ------ ----- ----- ----- ------ -- -----------
36 2 844 352 28 0,06 3168 ApntEx

gci c:\ | .{process{$_;continue}}


Directory: Microsoft.PowerShell.Core\FileSystem::C:\


Mode LastWriteTime Length Name
---- ------------- ------ ----
d---- 07.01.2006 13:37 ####
Get-ChildItem : Systemfehler
At line:1 char:4
+ gci <<<< c:\ | .{process{$_;continue}}

Note that the error message comes from Get-ChildItem in your example!

--
greetings
dreeschkind

"Roman Kuzmin" wrote:

> Replaying to <klumsy@gmail.com> I said that it would be perhaps more natural
> if 'continue' fails when looping is not found.
>
> But it does not fail in the examples Test1.ps1 and Test2.ps1.
>
> But it does fail in the example below and with very misleading message:
>
> CODE:
>
> gci c:\ | .{process{ $_; continue }}
>
> OUTPUT:
>
> Directory: Microsoft.PowerShell.Core\FileSystem::C:\
>
> Mode LastWriteTime Length Name
> ---- ------------- ------ ----
> d---- 23/04/2006 22:53 xxx
> Get-ChildItem : System error.
> At line:1 char:4
> + gci <<<< c:\ | .{process{ $_; continue }}
>
> Note the error message and where an error is designated. In the real code it
> was not so easy to find that 'continue' caused an error.
>
> So,
> *) why does 'continue' fails here and does not in Test1.ps1 and Test2.ps1?
> *) what about this strange error message?
>
> --
> Thanks,
> Roman
>

Some preliminary conclusions:

*) It looks like Get-ChildItem has mentioned problems.

*) 'break' used outside of looping has the same or similar effect as
'continue'.

*) If this break/continue effect is really designed then they theoretically
may be used for exiting all running scripts, in contrast to 'exit' which
exits the current script only. (The way looks a bit funny though).

It would be nice to get some remarks from MS guys.

--
Thanks,
Roman

Hi Roman, I found out some more things to add to your list:

#########################

1) Get-Item has the same problem (using wildcard)

PS> gi * | .{process{$_;continue}}


Directory: Microsoft.PowerShell.Core\FileSystem::E:\Eigene
Dateien\WindowsPowerShell


Mode LastWriteTime Length Name
---- ------------- ------ ----
d---- 27.10.2006 15:25 ###
Get-Item : Systemfehler
At line:1 char:3
+ gi <<<< * | .{process{$_;continue}}

#########################

2) It also 'kills' the extra lines that usually get added by the default
formatter at the end:

PS> get-date | .{process{$_;continue}}

Sonntag, 29. Oktober 2006 14:56:48
PS> get-date

Sonntag, 29. Oktober 2006 14:56:51


PS>

#########################

3) "Get-WmiObject -list" stops even before the first element gets returned:

PS> get-wmiobject -list | .{process{$_;continue}}

PS>(get-wmiobject -list)[0]


__SecurityRelatedClass

#########################

4) Get-Member also has this problem:

PS> get-member -i $pshome | .{process{$_;continue}}

PS> (get-member -i $pshome)[0]


TypeName: System.String

Name MemberType Definition
---- ---------- ----------
Clone Method System.Object Clone()

#########################

5) All the other get-cmdlets seem to work as expected:

get-psdrive
get-psprovider
get-pssnapin
get-command
get-alias
get-service
get-variable
get-history
get-tracesource
get-uiculture
get-culture
get-host
get-location
get-acl .
get-eventlog System
get-help get-

#########################

To sum it up, it looks like (at least) the following Cmdlets are affected:

* Get-ChildItem
* Get-Item
* Get-WmiObject
* Get-Member
* Out-Default (???)

--
greetings
dreeschkind

"Roman Kuzmin" wrote:

> Some preliminary conclusions:
>
> *) It looks like Get-ChildItem has mentioned problems.
>
> *) 'break' used outside of looping has the same or similar effect as
> 'continue'.
>
> *) If this break/continue effect is really designed then they theoretically
> may be used for exiting all running scripts, in contrast to 'exit' which
> exits the current script only. (The way looks a bit funny though).
>
> It would be nice to get some remarks from MS guys.
>
> --
> Thanks,
> Roman
>