Vista - Recursive text search, displaying filename

I want to seach through .cs files in a directory tree, looking for all
occurrences of a certain string. Easy enough.....

gci . -recu *.cs | % { gc $_.fullname } | select-string "DataExchangeService"

but this just shows me the lines of source code, it doesn't show the
filename that is was found in.

How would I get the filename displayed? Preferably it would only be
displayed for files that actually contain the search string, and omitted for
all others.

> I want to seach through .cs files in a directory tree, looking for all
> occurrences of a certain string. Easy enough.....
>
> gci . -recu *.cs | % { gc $_.fullname } | select-string
> "DataExchangeService"
>
> but this just shows me the lines of source code, it doesn't show the
> filename that is was found in.
>
> How would I get the filename displayed? Preferably it would only be
> displayed for files that actually contain the search string, and omitted
> for all others.

ie something like :

gci . -recu *.cs | where{$_|select-string -quiet "DataExchangeService"} |
foreach{$_.Name}

# use $_.FullName to get path+file name

or the following showing path+file name at the beginning of lines

gci . -recu *.cs | select-string "DataExchangeService"

You can complete it ie with:

gci . -recu *.cs | select-string "DataExchangeService" |
foreach{$_.Path+'`n'+$_.FileName+'`n'+$_.LineNumber+':'+$_.Line+'`n'}

or ... (depending the output you want).

Regards,

--
Jean - JMST
Belgium

In the example you're taking each file and streaming it's contents to the
input of select-string. Since select-string is just seeing a series of
strings disassociated from the file, it can't report the file name.
select-string knows how to read files so you can skip that extra step.
Here's how to search a bunch of files:

gci -rec -filter *.cs | select-string DataExchangeService

It's quite a bit simpler. Note that the output of select-string in this case
is a series of MatchInfo objects that contain the matching string, the path,
linenumber, patching pattern, etc. Also look at the -list option on
select-string if you just want a list of filenames. For example,

gci -rec -filter *.cs | select-string DataExchangeService -list |%{
$_.path }

will list all of the files containing the target string.

-bruce

--
Bruce Payette [MSFT]
Windows PowerShell Technical Lead
Microsoft Corporation
This posting is provided "AS IS" with no warranties, and confers no rights.



"forestial" <forestial@discussions.microsoft.com> wrote in message
news:2CB86E2D-B4C1-4234-9C3A-E4DF7E411EA7@microsoft.com...
>I want to seach through .cs files in a directory tree, looking for all
> occurrences of a certain string. Easy enough.....
>
> gci . -recu *.cs | % { gc $_.fullname } | select-string
> "DataExchangeService"
>
> but this just shows me the lines of source code, it doesn't show the
> filename that is was found in.
>
> How would I get the filename displayed? Preferably it would only be
> displayed for files that actually contain the search string, and omitted
> for
> all others.

Bruce,

Thank you. I had a feeling that should be simpler but somehow I missed the
correct usage of get-childitem to get it to work.

Speaking if which, and at the risk of going off the original topic, I see
that get-childitem allows a -Include parameter as well as the -Filter
parameter. It seems that these produce the same result, at least for my
search of the file system used in my original post.

I also see that the help for the -Filter parameter on gci says "accepts
wildcard characters?" is False; yet it appears to accept "*.cs" in my
example.

I also see that -Filter and -Include behave differently in this respect on
the Registry provider. -Filter does not seem to handle wild-carding on the
Name of registry keys.

I guess these differences are hinted at in the help for get-childitem. I
think what is happening is that the -Filter parameter is 'passed through' to
the provider to be interpreted, while the -Include parameter is 'expanded' by
the get-childitem cmdlet itself.

Would it not be possible to simplify this design somehow? Do we really need
the -Filter parameter? Perhaps we do, to accommodate different behavior of
providers, but it seems to come at a rather high cost in making a
conceptually simple and often used task (recursive directory listing) rather
complex.

Will Irwin

"Bruce Payette [MSFT]" wrote:

> In the example you're taking each file and streaming it's contents to the
> input of select-string. Since select-string is just seeing a series of
> strings disassociated from the file, it can't report the file name.
> select-string knows how to read files so you can skip that extra step.
> Here's how to search a bunch of files:
>
> gci -rec -filter *.cs | select-string DataExchangeService
>
> It's quite a bit simpler. Note that the output of select-string in this case
> is a series of MatchInfo objects that contain the matching string, the path,
> linenumber, patching pattern, etc. Also look at the -list option on
> select-string if you just want a list of filenames. For example,
>
> gci -rec -filter *.cs | select-string DataExchangeService -list |%{
> $_.path }
>
> will list all of the files containing the target string.
>
> -bruce
>
> --
> Bruce Payette [MSFT]
> Windows PowerShell Technical Lead
> Microsoft Corporation
> This posting is provided "AS IS" with no warranties, and confers no rights.
>
>
>

The Filter parameter is important, in that it allows you to do
provider-specific filtering. The globbing and wildcarding that we allow
shell-wide was based on the Filesystem syntax, so the difference isn't
immediately apparent. An equivalent statement on a SQL provider might look
like this, though:

PS SQL:\MyDatabase> dir Orders -recurse -filter "WHERE order_id > 10 AND
order_date in (...)"

The registry does not support a provider-specific filter, which is why you
saw no effect on the output. We have a bug open to thow an error in this
situation.

--
Lee Holmes [MSFT]
Windows PowerShell Development
Microsoft Corporation
This posting is provided "AS IS" with no warranties, and confers no rights.


"forestial" <forestial@discussions.microsoft.com> wrote in message
news118EDE1-3794-4123-8415-2DCF5EC5C73C@microsoft.com...
> Bruce,
>
> Thank you. I had a feeling that should be simpler but somehow I missed the
> correct usage of get-childitem to get it to work.
>
> Speaking if which, and at the risk of going off the original topic, I see
> that get-childitem allows a -Include parameter as well as the -Filter
> parameter. It seems that these produce the same result, at least for my
> search of the file system used in my original post.
>
> I also see that the help for the -Filter parameter on gci says "accepts
> wildcard characters?" is False; yet it appears to accept "*.cs" in my
> example.
>
> I also see that -Filter and -Include behave differently in this respect on
> the Registry provider. -Filter does not seem to handle wild-carding on
> the
> Name of registry keys.
>
> I guess these differences are hinted at in the help for get-childitem. I
> think what is happening is that the -Filter parameter is 'passed through'
> to
> the provider to be interpreted, while the -Include parameter is 'expanded'
> by
> the get-childitem cmdlet itself.
>
> Would it not be possible to simplify this design somehow? Do we really
> need
> the -Filter parameter? Perhaps we do, to accommodate different behavior
> of
> providers, but it seems to come at a rather high cost in making a
> conceptually simple and often used task (recursive directory listing)
> rather
> complex.
>
> Will Irwin
>
> "Bruce Payette [MSFT]" wrote:
>
>> In the example you're taking each file and streaming it's contents to
>> the
>> input of select-string. Since select-string is just seeing a series of
>> strings disassociated from the file, it can't report the file name.
>> select-string knows how to read files so you can skip that extra step.
>> Here's how to search a bunch of files:
>>
>> gci -rec -filter *.cs | select-string DataExchangeService
>>
>> It's quite a bit simpler. Note that the output of select-string in this
>> case
>> is a series of MatchInfo objects that contain the matching string, the
>> path,
>> linenumber, patching pattern, etc. Also look at the -list option on
>> select-string if you just want a list of filenames. For example,
>>
>> gci -rec -filter *.cs | select-string DataExchangeService -list |%{
>> $_.path }
>>
>> will list all of the files containing the target string.
>>
>> -bruce
>>
>> --
>> Bruce Payette [MSFT]
>> Windows PowerShell Technical Lead
>> Microsoft Corporation
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights.
>>
>>
>>
>