Vista - Trying to understand inconsistency.

I can see where
(dir | where {$_.name -like '*.exe'}).count
works the same as
(dir *.exe).count

But why does this work:
(dir -Recurse | where {$_.name -like '*.exe'}).count
But this does not:
(dir -recurse *.exe).count

There's probably a simple answer. Thanks in advance.

This seems to work

(dir -recurse -filter *.txt).count

Not 100% sure as to the why but this part of the help file for the recurse
parameter

Recurse works only when the path points to a container that has child
items, such as C:\Windows or C:\Windows\*, and not when it points to items
that do not have child items, such as C:\Windows\*.exe.

I think its saying that the (dir -recurse *.exe).count version is not able
to recurse through the child folders because its not recognising the path it
need to use
--
Richard Siddaway
Please note that all scripts are supplied "as is" and with no warranty
Blog: http://richardsiddaway.spaces.live.com/
PowerShell User Group: http://www.get-psuguk.org.uk


"Jason" wrote:

> I can see where
> (dir | where {$_.name -like '*.exe'}).count
> works the same as
> (dir *.exe).count
>
> But why does this work:
> (dir -Recurse | where {$_.name -like '*.exe'}).count
> But this does not:
> (dir -recurse *.exe).count
>
> There's probably a simple answer. Thanks in advance.

"Jason" <Jason@discussions.microsoft.com> wrote in message
news:EC8DD0F9-F449-45E8-AA3E-7B6E95DBC920@microsoft.com...
>I can see where
> (dir | where {$_.name -like '*.exe'}).count
> works the same as
> (dir *.exe).count
>
> But why does this work:
> (dir -Recurse | where {$_.name -like '*.exe'}).count
> But this does not:
> (dir -recurse *.exe).count
>
> There's probably a simple answer. Thanks in advance.

Try this:

@(dir -recurse *.exe).count

My guess is that your dir command is only returning a single FileInfo
object. System.IO.FileInfo doesn't have a "Count" property. Fortunately
there is a simple construct in PowerShell called an array subexpression that
you can use to tell PowerShell to create an array with a single element *if*
the inner expression evaluates to a single/scalar value. If the expression
evaluates to an array then the array subexpression syntax is no different
than just using naked parens (grouping) i.e. it does *not* wrap that array
in yet another array.

--
Keith

While what you say is completely true and good to remember, it is not
the whole issue in this case, at least I don't think so. I think what
he was missing was to use a "." with gci. Gci has some quirks which
are easier to just learn than try to explain. Many problems with gci
can be solved by remembering this pattern:

gci . -recurse *.exe | % { Next-Cmdlet -path $_.fullname }

HTH

Mike

> Try this:
>
> @(dir -recurse *.exe).count
>
> My guess is that your dir command is only returning a single FileInfo
> object. System.IO.FileInfo doesn't have a "Count" property. Fortunately
> there is a simple construct in PowerShell called an array subexpression that
> you can use to tell PowerShell to create an array with a single element *if*
> the inner expression evaluates to a single/scalar value. If the expression
> evaluates to an array then the array subexpression syntax is no different
> than just using naked parens (grouping) i.e. it does *not* wrap that array
> in yet another array.
>
> --
> Keith

"mikes.net" <michael.net@gmail.com> wrote in message
news:1172326924.460450.164130@s48g2000cws.googlegroups.com...
> While what you say is completely true and good to remember, it is not
> the whole issue in this case, at least I don't think so. I think what
> he was missing was to use a "." with gci. Gci has some quirks which
> are easier to just learn than try to explain. Many problems with gci
> can be solved by remembering this pattern:
>
> gci . -recurse *.exe | % { Next-Cmdlet -path $_.fullname }
>

Yeah you are absolutely correct.

--
Keith