find files

[e.group]

Hi all,
how can I find file/s (within a path), containing a given string?

Thanks for your help

[Andrzej Popielewicz]

[email]Cypherpunk@nyc.rr.com[/email] wrote:

>
>

Why do You reply to my answer. I did no ask.
Did not You understand my answer ? Here is explanation :

for in in *
do
if grep mystring $i ; then
echo string found in $i
read pause
fi
done

Andrzej
Andrzej

[Andrzej Popielewicz]

Pardon, small typo.

for i in *
do
if grep mystring $i ; then
echo found in $i
read pause
fi
done

Andrzej
P.S Shell handbook trick

[Andrzej Popielewicz]

Alan Coopersmith wrote:

>Andrzej Popielewicz <vasco@icpnet.pl> writes in comp.unix.solaris:
>|for in in *
>
>
>
>

You have mentioned my version with typo mistake.I have corrected it
already. I mean this double "in" in the first line with "for".

Andrzej

[Ken Gray]

In article <bgisca$73e$1@news.att.net.il>,
"e.group" <erezfain@hotmail.com> wrote:

> Hi all,
> how can I find file/s (within a path), containing a given string?
>
> Thanks for your help
>
>
>
>

I believe you're looking for a recursive grep. You can either grab the
rgrep source/binary from the web, or you could try one of the following:

find /some/path -exec grep <pattern> /dev/null {} \;

You need the /dev/null argument to let grep show you the filename -
otherwise, it will just print the match with no filename (not very
useful).

The second:

find /some/path | xargs grep <pattern>

This one can be a bit quicker, and usually handles large amounts of
files ok - the find variant can be a bit slow.

--
Ken

Real address krgray*at*verizon*dot*net

[Andrzej Popielewicz]

[email]Cypherpunk@nyc.rr.com[/email] wrote:

>
>I quoted the text of two posts and *two* message-IDs while
>making my reply.
>

It is okay .
By replying to Your message directly I do not quote message from
A.Coppersmith.
This is only what I wanted to say.
But If You wanted to quote also my message it is okay. You are always
allowed to do it.

>
>
>
>
>He asked how to search for strings. Your reply did not
>mention any commands that did string searches.
>

It is completely true. Your answer was more informative.
I wanted simply to suggest him, where he can find one of possible
solutions himself.

>
>
>

>> Here is explanation :
>>
>> for i in *
>> do
>> if grep mystring $i ; then
>> echo string found in $i
>> read pause
>> fi
>> done
>>
>>

>
>Personally, I don't think much of that way of coding.
>
>

You are free to have own opinion about that.

>Man find...
>
> -type c
> True if the type of the file is c, where c is b, c, d,
> D, f, l, p, or s for block special file, character
> special file, directory, door, plain file, symbolic
> link, fifo (named pipe), or socket, respectively.
>
>I showed 'find -type f'. Your code would grep against directory
>filenames, sockets, etc.
>

It is true. But You can specify :

for example

for i in *.c
or
for i in *.txt

etc. Reading the man for "for" he could find it out.

>
>Since my script had a 'cat -v' at the end, finding a string in
>a binary file is protected against throwing binary into the
>interactive window. Sometimes binary can really gephuck a window.
>
>

It is very true.And then helps only : stty sane.
But for search of strings in binaries we have something else , for
example "strings" as far as I remember. I have never used it but it
might be useful if he wants to search exactly binary files. He did not
specfy if he wants text files of binary files to be searched.
One can easily add file type checking to the above code too by the way.

>Also, it's not normal Unix style to pause the output, unless
>piping into 'more'.
>

Perhaps it is not normal Unix style but it is allowed and it allows to
look at output immediately and stop it at any time.
Well, it depends what You want to do. You can remove this or he can
remove this if he finds it not very useful.
It was only a proposition. One can easily design it in different way.
And one can easily add some extra functionality.
I like it. It allows me to search interactively and stop at any point.
Let leave to him if he finds this solution useful or not.
I hope now he has enough information to search his files.


It was a pleasure to discuss with You some Unix problem. I observed with
interest Your articles about "UNIX" problem.
I mean SCO versus IBM.
Keep posting if You find something important.



Andrzej

[Andrzej Popielewicz]

[email]Cypherpunk@nyc.rr.com[/email] wrote:

>Andrzej Popielewicz <vasco@icpnet.pl> wrote:
>
>
>Personally, I don't think much of that way of coding.
>
>
>

I have another variant of code I proposed ( please notice I do not
consider myself the inventor of the method , you can find it in books) .
Namely for searching recursively :

for i in 'locate *.c'
do
here_optionally_comes_file_type checking_function
if grep my string $i then ;
echo $i
perform_my_own_extra_function_having_200_lines_of_ code_or_even_more $i
read pause
fi
done

Question to all "members" in the thread :
will it be faster than using find or not ? Omit function
"perform_my...." in Your considerations. It was only mentioned to show
the flexibilty of the above code.
The file extension .c is also chosen arbitrary.

My bid is : it will be faster.

Andrzej

[Alan Coopersmith]

Andrzej Popielewicz <vasco@icpnet.pl> writes in comp.unix.solaris:
|I have another variant of code I proposed ( please notice I do not
|consider myself the inventor of the method , you can find it in books) .
|Namely for searching recursively :
|
|for i in 'locate *.c'

locate is not a standard part of Solaris. On those systems that have
it, it generally uses a database of the entire filesystem, not
restricted to just one directory or hierarchy, and depending on when the
database was last generated, may be out of date with respect to the
current contents of the file system. (You also want ` instead of ' ).

|will it be faster than using find or not ?

It depends. With find & grep I normally don't run a command once per
file, but use xargs to exec only once per large sized group of files.
That can be faster than your method depending on how many you exec.

--
__________________________________________________ ______________________
Alan Coopersmith [email]alanc@alum.calberkeley.org[/email]
[url]http://www.CSUA.Berkeley.EDU/~alanc/[/url] aka: [email]Alan.Coopersmith@Sun.COM[/email]
Working for, but definitely not speaking for, Sun Microsystems, Inc.