On a GNU box I might do something like this:

find . -type f -exec grep -q foo {} \; -print

to find all the files containing the string "foo". 
Solaris grep does not accept -q. 
Does this  mean that  Solaris people never  do recursive greps,  or is
there some other way? 

-chris

Chris Majewski <majewski@cs.ubc.ca> writes:

> On a GNU box I might do something like this:
> 
> find . -type f -exec grep -q foo {} \; -print

A solaris user would use

  find . -type f -exec grep -l foo {} +

Chris Majewski <majewski@cs.ubc.ca> writes:

> On a GNU box I might do something like this:
> 
> find . -type f -exec grep -q foo {} \; -print
> 
> to find all the files containing the string "foo". 
> Solaris grep does not accept -q. 
> Does this  mean that  Solaris people never  do recursive greps,  or is
> there some other way? 
> 
> -chris

/usr/xpg4/bin/grep accepts -q

Cool! What's the + though? (I can't seem to get that to work,
nor is it in my "find" manpage).

-chris

Juergen Keil <jk@tools.de> writes:

> Chris Majewski <majewski@cs.ubc.ca> writes:
> 
> > On a GNU box I might do something like this:
> > 
> > find . -type f -exec grep -q foo {} \; -print
> 
> A solaris user would use
> 
>   find . -type f -exec grep -l foo {} +

Thanks.    BTW,   I've    never    understood   "/usr/xpg4/bin"    and
"/usr/ccs/bin". Does anybody  know what xpg4 and ccs  refer to, or why
the binaries in /usr/bin took precedence over them in Solaris? 

-chris

Thomas Tornblom <thomas@Hax.SE.remove-to-reply> writes:

> Chris Majewski <majewski@cs.ubc.ca> writes:
> 
> > On a GNU box I might do something like this:
> > 
> > find . -type f -exec grep -q foo {} \; -print
> > 
> > to find all the files containing the string "foo". 
> > Solaris grep does not accept -q. 
> > Does this  mean that  Solaris people never  do recursive greps,  or is
> > there some other way? 
> > 
> > -chris
> 
> /usr/xpg4/bin/grep accepts -q

Chris Majewski wrote:
> On a GNU box I might do something like this:
> 
> find . -type f -exec grep -q foo {} \; -print
> 
> to find all the files containing the string "foo". 
> Solaris grep does not accept -q. 

Well, you could use Solaris egrep instead, which supports the "-s"
option, which does the same thing as GNU grep's "-q":

         find . -type f -exec egrep -s foo '{}' ';' -print

Or use "-q" with /usr/xpg4/bin/grep on Solaris:

         find . -type f -exec /usr/xpg4/bin/grep -q foo '{}' ';' -print

Or you could have grep print the filenames of the files that match,
instead of having find print them in response to grep's return code:

         find . -type f -exec grep -l foo '{}' ';'

I find the last way to be the most natural of the above.

> Does this  mean that  Solaris people never  do recursive greps,  or is
> there some other way? 

There is, in fact, another way.  The example you give will fork()
a new process and exec() a new instance of grep for every file
that find examines.  Another way to do this is to use xargs to
read a bunch of filenames as output from find, and then run grep
on as many as possible at once:

         find . -type f -print | xargs grep -l foo

This last way is sort of the standard Unix way to do it.  It
won't work properly if you have filenames with whitespace in them
(that trips up xargs, which strangely doesn't have an option
to ignore whitespace) but otherwise, it works fine and you'll
find that it should work a LOT faster.

   - Logan

[Juergen Keil]:
>
>   Chris Majewski <majewski@cs.ubc.ca> writes:
>   
>   > On a GNU box I might do something like this:
>   > 
>   > find . -type f -exec grep -q foo {} \; -print

more typical for a GNU user would be:

    grep -rl foo .

>   A solaris user would use
>   
>     find . -type f -exec grep -l foo {} +

actually, he should use

    find . -type f -exec grep -l foo /dev/null {} +

-- 
Kjetil T.			|  read and make up your own mind
				|  http://www.cactus48.com/truth.html

[Chris Majewski]:
>
>   Solaris grep does not accept -q. 

put /usr/xpg4/bin before /usr/bin in your path.

-- 
Kjetil T.			|  read and make up your own mind
				|  http://www.cactus48.com/truth.html

On 11 Sep 2003, Chris Majewski wrote:

Please stop top posting.

> Thanks.    BTW,   I've    never    understood   "/usr/xpg4/bin"    and

/usr/xpg4/bin contains programs that are compliant with the
XPG/4 and later specifications, if thedefault Solaris ones
aren't already compliant.

> "/usr/ccs/bin". Does anybody  know what xpg4 and ccs  refer to, or why

/usr/ccs/bin = binaries for the C Compilation System.

> the binaries in /usr/bin took precedence over them in Solaris?

Becasue that's what your PATH specified.

-- 
Rich Teer, SCNA, SCSA

President,
Rite Online Inc.

Voice: +1 (250) 979-1638
URL: http://www.rite-online.net

Chris Majewski <majewski@cs.ubc.ca> writes:

> Cool! What's the + though? (I can't seem to get that to work,
> nor is it in my "find" manpage).

From Solaris 9 "man find":
---
     -exec command
           True if the executed command returns a zero  value  as
           exit  status. The end of command must be punctuated by
           an escaped semicolon (;). A  command  argument  {}  is
           replaced  by  the current path name. If the last argu-
           ment to -exec is {} and you specify + rather than  the
           semicolon  (;),  the  command  will  be  invoked fewer
           times, with {} replaced by groups of pathnames.

---

You can use that instead of xargs

> 
> -chris
> 
> Juergen Keil <jk@tools.de> writes:
> 
> > Chris Majewski <majewski@cs.ubc.ca> writes:
> > 
> > > On a GNU box I might do something like this:
> > > 
> > > find . -type f -exec grep -q foo {} \; -print
> > 
> > A solaris user would use
> > 
> >   find . -type f -exec grep -l foo {} +

Thomas

Chris Majewski wrote:

> Thanks.    BTW,   I've    never    understood   "/usr/xpg4/bin"    and
> "/usr/ccs/bin". Does anybody  know what xpg4 and ccs  refer to, or why
> the binaries in /usr/bin took precedence over them in Solaris? 

The binaries in /usr/bin "take precedence" because Sun cares about
not breaking compatibility with stuff its customers might already
be using.  Sun could have just ripped out the grep, etc., that are
in /usr/bin and replaced them with new versions (the ones in
/usr/xpg4/bin), but since their behavior is slightly different,
this could cause a shell script to do the wrong thing if it relies
on something specific about the behavior of one of the original
/usr/bin versions.

And yes, there is a time to move on, throw out the old stuff,
and get used to doing things the new way, but Sun's approach
seems to be that the customers ought to get to do decide on
their own when they want to do that.  :-)

   - Logan

Rich Teer <rich.teer@rite-group.com> writes:

> > the binaries in /usr/bin took precedence over them in Solaris?
> 
> Becasue that's what your PATH specified. 

What I  meant was, /usr/bin is  a standard location for  binaries - in
that sense, /usr/bin/grep  "takes precedence" over /usr/xpg4/bin/grep,
regardless of your PATH.

-chris

Logan Shaw <lshaw-usenet@austin.rr.com> writes:

> Chris Majewski wrote:
> 
> > Thanks.    BTW,   I've    never    understood   "/usr/xpg4/bin"    and
> > "/usr/ccs/bin". Does anybody  know what xpg4 and ccs  refer to, or why
> > the binaries in /usr/bin took precedence over them in Solaris?
> 
> The binaries in /usr/bin "take precedence" because Sun cares about
> not breaking compatibility with stuff its customers might already
> be using.  Sun could have just ripped out the grep, etc., that are
> in /usr/bin and replaced them with new versions (the ones in
> /usr/xpg4/bin), but since their behavior is slightly different,
> this could cause a shell script to do the wrong thing if it relies
> on something specific about the behavior of one of the original
> /usr/bin versions.
> 
> And yes, there is a time to move on, throw out the old stuff,
> and get used to doing things the new way, but Sun's approach
> seems to be that the customers ought to get to do decide on
> their own when they want to do that.  :-)
> 

I   see.  I   had   previously  assumed   (well   ok:  guessed)   that
/usr/{xpg4,ccs}/bin predated  /usr/bin, but I  see that (at  least for
xpg4) this is not the case.  Maybe they should have a /usr/xpg4/README
that explains all this stuff. 

-chris

On 11 Sep 2003, Chris Majewski wrote:

> I   see.  I   had   previously  assumed   (well   ok:  guessed)   that
> /usr/{xpg4,ccs}/bin predated  /usr/bin, but I  see that (at  least for
> xpg4) this is not the case.  Maybe they should have a /usr/xpg4/README
> that explains all this stuff.

There's no README, but man filesystem will explain all.

-- 
Rich Teer, SCNA, SCSA

President,
Rite Online Inc.

Voice: +1 (250) 979-1638
URL: http://www.rite-online.net

In article <1rd6e716ez.fsf@glesvat.ifi.uio.no>,
	Kjetil Torgrim Homme <kjetilho@yksi.ifi.uio.no> writes:
> [Juergen Keil]:
>>
>>   Chris Majewski <majewski@cs.ubc.ca> writes:
>>   
>>   > On a GNU box I might do something like this:
>>   > 
>>   > find . -type f -exec grep -q foo {} \; -print
> 
> more typical for a GNU user would be:
> 
>     grep -rl foo .
> 
>>   A solaris user would use
>>   
>>     find . -type f -exec grep -l foo {} +
> 
> actually, he should use
> 
>     find . -type f -exec grep -l foo /dev/null {} +

With grep -l, you don't need the /dev/null to ensure it will print
names even if there were otherwise only one.  Example:

$ grep -l nobody /etc/aliases
/etc/aliases
$ 

Therefore, it's more efficient not to use it in that situation (avoids
needless open/read-returning-EOF/close of /dev/null).

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

Rich Teer wrote:
> On 11 Sep 2003, Chris Majewski wrote:
> 
> Please stop top posting.
> 
> 
>>Thanks.    BTW,   I've    never    understood   "/usr/xpg4/bin"    and
> 
> 
> /usr/xpg4/bin contains programs that are compliant with the
> XPG/4 and later specifications,

XPG being X/Open Portability Guide.


> 
> 
>>"/usr/ccs/bin". Does anybody  know what xpg4 and ccs  refer to, or why
> 
> 
> /usr/ccs/bin = binaries for the C Compilation System.

C Compilation Subsystem, to be deeply pedantic.

A long long time ago, when AT&T sold Unix System V Release 2 and 3 on 
the 3B range, you'd get your C compiler on a separate set of floppies 
called the C Compilation Subsystem (there were other "subsystems", 
frinstance the lp subsystem). Sort of like packages in the SVR4 model.

The abbreviation "ccs" stuck.  It's a bit of a misnomer, though, since 
most of the stuff in the CCS is *not* compiler-specific (things like 
"make" and "nm" and so on).  Perhaps it was Code Compilation 
Subsystem...  Think I'll drag the 3B2/500 and assorted floppies out from 
under my kitchen table and have a look this weekend.

-- 
Tony

Thomas Tornblom wrote:
> Chris Majewski <majewski@cs.ubc.ca> writes:
> 
> 
>>Cool! What's the + though? (I can't seem to get that to work,

Odd. You're not doing

find blah {} \+

are you?  Miss out the backslash if so.

>>nor is it in my "find" manpage).
> 
> 
> From Solaris 9 "man find":
{snip}       If the last argu-
>            ment to -exec is {} and you specify + rather than  the
>            semicolon  (;),  the  command  will  be  invoked fewer
>            times, with {} replaced by groups of pathnames.

The ability to use '+' instead of ';' has been in find(1) since Solaris 
2.3 at least, though not in the manual page until Solaris 9 (just in 
case anyone's wondering).


-- 
Tony