I'm using the following at the moment.

if ($found = Get-ChildItem C:\* -Include $filename -Recurse|select-
object -first 1)
{Do-SomethingWith $found}

At first I thought it was just taking a while to find the file.
Then I realized that the search was continuing even after it was
found.
Is there a better way to search for a file when I expect there will be
only one copy and if there happen to be more I want to ignore them?

RickB wrote:

> I'm using the following at the moment.
>
> if ($found = Get-ChildItem C:\* -Include $filename -Recurse|select-
> object -first 1)
> {Do-SomethingWith $found}
>
> At first I thought it was just taking a while to find the file.
> Then I realized that the search was continuing even after it was
> found.
> Is there a better way to search for a file when I expect there will be
> only one copy and if there happen to be more I want to ignore them?

This has come up a few times before here and a private mailing list I'm on.

There's no way I'm aware of to stop the processing of cmdlets until it
has processed all the objects "in its path".

The same goes for reading the Windows event log, for example, even if
one might do a select-object, PowerShell will process *all* the records
in the event log before returning.

Marco

--
Microsoft MVP - Windows PowerShell
http://www.microsoft.com/mvp

PowerGadgets MVP
http://www.powergadgets.com/mvp

Blog:
http://marcoshaw.blogspot.com

Hello RickB,

> if ($found = Get-ChildItem C:\* -Include $filename -Recurse|select-
> object -first 1)
> {Do-SomethingWith $found}

Rick;

Try this:

do
{
if (Get-ChildItem C:\* -Include $filename -Recurse|select-object -first 1)
{
$found = $true
}
}while($found -ne $true)
{Do-SomethingWith $found}

On Apr 23, 12:58*pm, "Marco Shaw [MVP]"
<marco.shaw@_NO_SPAM_gmail.com> wrote:

> RickB wrote:

> > I'm using the following at the moment.

>

> > if ($found = Get-ChildItem C:\* -Include $filename -Recurse|select-
> > object -first 1)
> > {Do-SomethingWith $found}

>

> > At first I thought it was just taking a while to find the file.
> > Then I realized that the search was continuing even after it was
> > found.
> > Is there a better way to search for a file when I expect there will be
> > only one copy and if there happen to be more I want to ignore them?

>
> This has come up a few times before here and a private mailing list I'm on..
>
> There's no way I'm aware of to stop the processing of cmdlets until it
> has processed all the objects "in its path".
>
> The same goes for reading the Windows event log, for example, even if
> one might do a select-object, PowerShell will process *all* the records
> in the event log before returning.
>
> Marco
>
> --
> Microsoft MVP - Windows PowerShellhttp://www.microsoft.com/mvp
>
> PowerGadgets MVPhttp://www.powergadgets.com/mvp
>
> Blog:http://marcoshaw.blogspot.com

I was somewhat afraid of that.
There may be some limited usefullness to this method if anyone else is
desperate...

$file = &{trap {$error[0].exception.message;continue}Get-ChildItem C:
\* -INCLUDE $name -Recurse|%{throw $_}}

Thanks.

Try this:
$found = $(foreach ($item in ls C:\* -i $filename -r) {$item; break})
if ($found) {Do-SomethingWith $found}

--
Kiron

On Apr 23, 3:14*pm, "Kiron" <Ki...@xxxxxx> wrote:

> Try this:
> $found = $(foreach ($item in ls C:\* -i $filename -r) {$item; break})
> if ($found) {Do-SomethingWith $found}
>
> --
> Kiron

Sorry, no.
ls must complete before foreach even starts so I'm waiting just as
long.

But I expanded on my previous though.
This actually returns the object.

$file = &{trap {$i;continue}
Get-ChildItem C:\* -INCLUDE $name -Recurse|%{$i = $_;throw
$_}}

Sorry, my mistake. You can pass the file's name to -filter instead of using wildcards in -path and passing the file's name to -include:

ls c:\ $name -r | % {$file = $_; break}
$file

--
Kiron

RickB wrote:

> I'm using the following at the moment.
>
> if ($found = Get-ChildItem C:\* -Include $filename -Recurse|select-
> object -first 1)
> {Do-SomethingWith $found}

Just to make sure I've understood properly, you're wondering if you can
have the pipeline stop at the first match when you run this part:
"gci c:\* -inc $filename -rec|select -first 1"

Correct?

Marco

On Apr 23, 6:02*pm, "Kiron" <Ki...@xxxxxx> wrote:

> Sorry, my mistake. You can pass the file's name to -filter instead of using wildcards in -path and passing the file's name to -include:
>
> ls c:\ $name -r | % {$file = $_; break}
> $file
>
> --
> Kiron

I do like break better than throw however this creates output

function test($name) {
$file = &{trap {$i;continue} ls C:\* -I $name -R|%{$i = $_;throw $_}}
"file is $file"}

This doesn't.
function test($name) {
ls c:\ $name -r|%{$file = $_;break}
"file is $file"}

On Apr 24, 6:47*am, "Marco Shaw [MVP]" <marco.shaw@_NO_SPAM_gmail.com>
wrote:

> RickB wrote:

> > I'm using the following at the moment.

>

> > if ($found = Get-ChildItem C:\* -Include $filename -Recurse|select-
> > object -first 1)
> > {Do-SomethingWith $found}

>
> Just to make sure I've understood properly, you're wondering if you can
> have the pipeline stop at the first match when you run this part:
> "gci c:\* -inc $filename -rec|select -first 1"
>
> Correct?
>
> Marco

I think the short answer is Yes.

Until recently, Windows was never my primary environment.
My 'native' environment is NSK (aka Tandem) where machines
usually have 16 cpu's. Everything executes in a pipeline.
Most are dynamic and steps always execute concurrently.

So I see right away that unless the first step waited until
the last step was done there could be lots of steps in progress
at the point where we decide to stop processing.

I'm not sure of MS intention for PS. Perhaps stopping the
pipeline is easy because steps already wait. If not, or
there is an intention to take advantage of multi-processor
capabilities, it may be necessary to use || vs | or some such
syntax to allow for pipelines that must wait vs those whose
steps can execute concurrently.

Either way, your pipelines are essentially a loop.
Allowing them to be labeled and then making 'break' work
on them like any other loop would certainly be nice.

Later, when concurrency is implemented you could
just not allow || pipelines to be labeled. That would
force you to throw but, by definition, || needs cleanup
anyway and throwing lets you define what cleanup to do.

If you are already doing concurrent steps then just
reverse things. || can be labeled.