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

Thanks for your help

Andrzej Popielewicz <vasco@icpnet.pl> wrote:
>   "e.group" wrote:
>   
>  > Hi all,
>  > how can I find  file/s (within a path), containing a given string?
>  >
>  > Thanks for your help
>   
>   man for

find < path > -type f -print | xargs grep "a given string" /dev/null | cat -v

Cypherpunk@nyc.rr.com 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

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 <vasco@icpnet.pl> wrote:
>  Cypherpunk@nyc.rr.com wrote:
>  >
>   Why do You reply to my answer. I did  no ask.

You are apparently new to Usenet.

I replied within the thread.

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

>   Did not You understand my answer?

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

>   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.

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.

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.

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

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

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

Cypherpunk@nyc.rr.com 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
 

Cypherpunk@nyc.rr.com 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 

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                              alanc@alum.calberkeley.org
http://www.CSUA.Berkeley.EDU/~alanc/       aka: Alan.Coopersmith@Sun.COM
  Working for, but definitely not speaking for, Sun Microsystems, Inc.

e.group wrote:
> Hi all,
> how can I find  file/s (within a path), containing a given string?
> 
> Thanks for your help
> 
> 
> 
> 
find /path/of/dir -type f -exec grep -l "find this string" {} \;

Alexander N. Spitzer <alex@spitzer.remove-if-not-spam.org> wrote:
>   e.group wrote:
>   > Hi all,

	Hi! Excitement! Meth lab in North Carolina brings WMD charges!  Dubya RULEZ!!!

>   > how can I find  file/s (within a path), containing a given string?
>
>   find /path/of/dir -type f -exec grep -l "find this string" {} \;

	While that will work, it is very inefficient because it execs grep for
	each file. Use:

	find path -type f -print | xargs grep -l /dev/null

-am	© 2003

Anthony Mandic wrote:

> Alexander N. Spitzer <alex@spitzer.remove-if-not-spam.org> wrote:

>>  find /path/of/dir -type f -exec grep -l "find this string" {} \;
> 
> 	While that will work, it is very inefficient because it execs grep for
> 	each file. Use:
> 
> 	find path -type f -print | xargs grep -l /dev/null

Or leave off the /dev/null; it's normally good with this sort
of find | xargs incantation, but it's not necessary if you're
doing grep with the "-l".

Also, the find | xargs method will fail if the filenames have spaces
in them.  Using the method where you give "find" the "-exec" argument
will solve the problem.  (I've never understood why xargs doesn't
have some kind of switch that makes it consider ONLY newlines as
the record separator...)

   - Logan

Logan Shaw <lshaw-usenet@austin.rr.com> wrote:
>   Anthony Mandic <mailto:am@peppler.org>
>   <mailto:anthony@isug.com>
>   <mailto:amandic@start.com.au> wrote:
>   > Alexander N. Spitzer <alex@spitzer.remove-if-not-spam.org> wrote:
>   
>   >>  find /path/of/dir -type f -exec grep -l "find this string" {} \;
>   > 
>   >       While that will work, it is very inefficient because it execs grep for
>   >       each file. Use:
>   > 
>   >       find path -type f -print | xargs grep -l /dev/null
>   
>   Or leave off the /dev/null; it's normally good with this sort
>   of find | xargs incantation, but it's not necessary if you're
>   doing grep with the "-l".

	Ah, yep.

>   Also, the find | xargs method will fail if the filenames have spaces
>   in them.

	Well, like, everybody knows that don't they? ;-)

>   Using the method where you give "find" the "-exec" argument
>   will solve the problem.  (I've never understood why xargs doesn't
>   have some kind of switch that makes it consider ONLY newlines as
>   the record separator...)

	Once again the Apple Unix running on my iMac impresses me:

~/tmp #   ll
total 16
-rw-r--r--   1 root  wheel     5 Sep  6 06:18 aaa bbb
-rw-r--r--   1 root  wheel     8 Sep  6 06:24 rewer tt
~/tmp #   cat aaa\ bbb 
zork
~/tmp #   cat rewer\ tt 
wwweeez
~/tmp #   find . -type f -print0|xargs -0 grep z
../aaa bbb:zork
../rewer tt:wwweeez
~/tmp #   find . -type f -print0 | xargs -0 grep zo
../aaa bbb:zork
~/tmp #   

	I'm sure McNealy is too busy inking deals to pay the likes of Siebel Systems
	big bucks to notice the 'find' command could use a friendly tweak.

	Not on the radar.

-am	© 2003

In article <3f59ba83$0$375$c3e8da3@news.astraweb.com>,
Anthony Mandic  <if@hotmail.com> wrote:
>>   > Alexander N. Spitzer <alex@spitzer.remove-if-not-spam.org> wrote:
>>   
>>   >>  find /path/of/dir -type f -exec grep -l "find this string" {} \;
>>   > 
>>   >       While that will work, it is very inefficient because it execs grep for
>>   >       each file. Use:
>>   > 
>>   >       find path -type f -print | xargs grep -l /dev/null
....
>>   Also, the find | xargs method will fail if the filenames have spaces
>>   in them.
>
>	Well, like, everybody knows that don't they? ;-)
>
>>   Using the method where you give "find" the "-exec" argument
>>   will solve the problem.  (I've never understood why xargs doesn't
>>   have some kind of switch that makes it consider ONLY newlines as
>>   the record separator...)
>
>	Once again the Apple Unix running on my iMac impresses me:
>
>~/tmp #   ll
>total 16
>-rw-r--r--   1 root  wheel     5 Sep  6 06:18 aaa bbb
>-rw-r--r--   1 root  wheel     8 Sep  6 06:24 rewer tt

Creating path names with spaces inside is a real bad idea.

But POSIX has a method to deal with this problem:

	find path -type f -exec grep -l bla {} +

>~/tmp #   cat aaa\ bbb 
>zork
>~/tmp #   cat rewer\ tt 
>wwweeez
>~/tmp #   find . -type f -print0|xargs -0 grep z
>./aaa bbb:zork
>./rewer tt:wwweeez
>~/tmp #   find . -type f -print0 | xargs -0 grep zo
>./aaa bbb:zork
>~/tmp #   

You don't need this, Solaris always did support the '+' method documented
with man find.

-- 
EMail:joerg@schily.isdn.cs.tu-berlin.de (home) J�rg Schilling D-13353 Berlin
      js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
      schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Joerg Schilling <js@cs.tu-berlin.de> wrote:
>   Anthony Mandic <mailto:am@peppler.org>
>   <mailto:anthony@isug.com>
>   <mailto:amandic@start.com.au> wrote:
>   >
>   >       Once again the Apple Unix running on my iMac impresses me:
>   >
>   >~/tmp #   ll
>   >total 16
>   >-rw-r--r--   1 root  wheel     5 Sep  6 06:18 aaa bbb
>   >-rw-r--r--   1 root  wheel     8 Sep  6 06:24 rewer tt
>   
>   Creating path names with spaces inside is a real bad idea.

	Not on Apple Unix. Root's default shell is tcsh, which has no
	problems doing file completions on filenames with spaces.
>   
>   But POSIX has a method to deal with this problem:
>   
>           find path -type f -exec grep -l bla {} +
>   
>   Solaris always did support the '+' method documented with man find.

	You're right. I keep forgetting about that.

	But as far as it being docmented, it must have happened in Solaris 9.

	Anyway, yes, the 'exec...+' is the definitive solution under Solaris.

-am	� 2003

Anthony Mandic wrote:
> 
> Joerg Schilling <js@cs.tu-berlin.de> wrote:

> >   Creating path names with spaces inside is a real bad idea.
> 
>         Not on Apple Unix. Root's default shell is tcsh, which has no
>         problems doing file completions on filenames with spaces.

Maybe it works on Apple, but its not exactly very portable and easy to
deal with. An underscore or hyphen has the same effect (to indicate
some separation), but presents far less hassle when moving a file
between different systems. 

-- 
Dr. David Kirkby,
Senior Research Fellow,
Department of Medical Physics,
University College London,
11-20 Capper St, London, WC1E 6JA.
Website: http://www.medphys.ucl.ac.uk/~davek
Author of 'atlc' http://atlc.sourceforge.net/

Cypherplug wrote:

> Oh, no doubt about it. There are no filenames (that I know of) on any
> of the Solaris systems I'm involved with that have embedded spaces.

	LOL! Are "youz" too dumb to add them "youzself", Plugger?

> Which is probably why I didn't care about it in my first 'xargs' reply.

	LOL! Neither does anyone else, Plugger.

> But that wasn't a "production quality" bit of coding.

	Since "youz" is just a script-kiddie, Plugger, what else could
	we expect from "youz".

-am	� 2003

Dr. David Kirkby <drkirkby@ntlworld.com> wrote:
>   Anthony Mandic <mailto:am@peppler.org>
>   <mailto:anthony@isug.com>
>   <mailto:amandic@start.com.au> wrote:
>   > 
>   > Joerg Schilling <js@cs.tu-berlin.de> wrote:
>   
>   > >   Creating path names with spaces inside is a real bad idea.
>   > 
>   >         Not on Apple Unix. Root's default shell is tcsh, which has no
>   >         problems doing file completions on filenames with spaces.
>   
>   Maybe it works on Apple, but its not exactly very portable and easy to
>   deal with. An underscore or hyphen has the same effect (to indicate
>   some separation), but presents far less hassle when moving a file
>   between different systems. 

	Oh, no doubt about it. There are no filenames (that I know of) on any
	of the Solaris systems I'm involved with that have embedded spaces.

	Which is probably why I didn't care about it in my first 'xargs' reply.

	But that wasn't a "production quality" bit of coding.

-am	© 2003

According to Logan Shaw  <lshaw-usenet@austin.rr.com>:
:Also, the find | xargs method will fail if the filenames have spaces
:in them.  

I _think_ that if you do

gfind blah blah blah -print0 | gxargs --null more blah blah

that the problems with spaces, quotation marks, backslashs, etc. is
resolved...


-- 
<URL: http://wiki.tcl.tk/ > <URL: http://www.tcl.tk/ >
Even if explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.
<URL: mailto:lvirden@yahoo.com > <URL: http://www.purl.org/NET/lvirden/ >

In article <bjncf1$nu1$1@srv38.cas.org>,
	lvirden@yahoo.com writes:
> 
> According to Logan Shaw  <lshaw-usenet@austin.rr.com>:
>:Also, the find | xargs method will fail if the filenames have spaces
>:in them.  
> 
> I _think_ that if you do
> 
> gfind blah blah blah -print0 | gxargs --null more blah blah
> 
> that the problems with spaces, quotation marks, backslashs, etc. is
> resolved...

Use the plus thingie (documented in Solaris 9, but present _much_ earlier
(Solaris 2.3 has been mentioned, I think):

find path ... -exec program arg {} +

(plus instead of quoted or escaped semicolon)

That gathers up multiple args like xargs, but without the space, newline,
or quote problems.  The one catch is that the {} _must_ be the last thing
before the +, or it won't work (think about it - it would be more obnoxious
to expand a list of files somewhere in the middle of other args than at the
end).


-- 
mailto:rlhamil@mindwarp.smart.net  http://www.smart.net/~rlhamil