grep "XXXX" `find . -name "*.[ch]"`

[W1GUH]

That's what I use on Unix to recursively search for a pattern (XXXX) in .c and .h files. The single quotes are "tics" -- the character below the tilde in the upper left corner of the keyboard.

I appears that that doesn't work in Red Hat Linux, maybe because the "tic" means something else in linux? The part of the command within the tics works on linux, recursively finding c files, but it does something different when I enclose in it tics.

Anyone know how to search recursively for patterns in files on linux? Tnx.

[KC2UGV]

the ` character in Bash means "explode the following command, so it should work. BUT, I would just suggest this:

find ./ -name "*.[ch]" -exec grep {} "foo" ;\

[W1GUH]

That one didn't work with Red Hat, but

fine ./ -name | grep "foo"

does.

Well, DUH, of course it will.

Awwwww....where's the Homer Simpson DOH! when you really neet it? :snicker:

[KC2UGV]

That'll do it too. More than one way to pipe a command, I always say :bbh:

[W1GUH]

Actually, no...that's all worng. :oops: The pipe's in the wrong direction. Back to square one.

Thanks, anyway.

I'll take a close look at that "exec" command....seems a step in the right direction.

[KC2UGV]

This should do it:
find ./ -name "*.[ch]" -exec grep "foo" {} \;

Had the args for grep backwards.

[ka8ncr]

That one didn't work with Red Hat, but

fine ./ -name | grep "foo"

does.

Well, DUH, of course it will.

Awwwww....where's the Homer Simpson DOH! when you really neet it? :snicker:

Doesn't find accept wildcards?

[W1GUH]

This should do it:
find ./ -name "*.[ch]" -exec grep "foo" {} \;

Had the args for grep backwards.

That does it, thanks a bunch. Sorry it took so long to check it out...I've been away from a linux box til tonight. Well, that and I was too busy (lazy?) to check it over the weekend. Plus, I wanted to test my memory of the Unix command on a Unix box.

Leads me to more general question....

Can anyone recommend a good linux primer that'll decipher this stuff? I tried web searches to find out what the "tic" does in both OS's (I get different results on Unix and linux), and can't find anything succinct and/or written for a novice. (Someday my "speed" will hit 13, and then 20! :lol: )

I learned the original Unix command from a guru in the usual way...memorized it.

[KC2UGV]

http://tldp.org/HOWTO/Bash-Prog-Intro-HOWTO.html

:)

And this is almost all the documentation you'll ever need:
http://tldp.org/

[W1GUH]

Thanks for the links...they look like good quick look-up pages.

But they didn't help my current quest....finding out about that "back tick" (finally learned it's proper name) operator. That's been a very tough search, but I finally learned about it in Barnes & Nobel tonight....sitting on the floor, looking through all the linux books on the shelf.

Went through about six of them until I FINALLY found out what it means....

"Use the output of the enclosed command as input to the previous command." Called command substitution.
Gripe #1 -- never did find that on the web. Sure, if I would have known about "command substitution", I could have searched for that.

I also read that it recommended to use $() instead. Book didn't really say why, just gave the suggestion. Well, OK...

So I ran home to try out my new found knowledge and, well, my Ubuntu linux actually likes:

grep XXXX `find . -name "*.[ch]"`

Works just fine. So does grep XXXX $(find . -name *.c)

But I couldn't make it work on a Red Hat linux box. ???

Maybe the most important thing I learned while using Barnes & Nobel as a library is what I really want to learn is Command Line Scripting. It looked as if that's where all the stuff about these special characters & stuff is described. Uh-oh....keep this quiet...word of this gets around I might get tasked with dealing with make files. Horrors! :lol:

One thing I couldn't find anything about (looking in the indices of a bunch of books) is that "exec". I saw it mentioned briefly once....but the text didn't say anything about what it is or how to use it.

Just reportin' one guy's struggle to get into linu/unix.

I'm getting a very strong impression that most (Almost all? All?) unix/linux types primarily learn through osmosis -- being in a SW lab with gurus and wizards who share their knowledge (and who probably learned the same way!)

This is contrast to, say the c family of languages where primers are available to lead you by the hand. The best I found are C Primer Plus and C++ Primer Plus. Not only are that very well written and easy to learn from, the author has a GREAT sense of humor!

[KC2UGV]

With the osmosis part, you're mostly correct. Lots of questions asked, and some not answered. Lots of experimenting too :)

As for that exec thing:
http://unixhelp.ed.ac.uk/CGI/man-cgi?find
-exec command {} +
This variant of the -exec option runs the specified command on
the selected files, but the command line is built by appending
each selected file name at the end; the total number of invoca-
tions of the command will be much less than the number of
matched files. The command line is built in much the same way
that xargs builds its command lines. Only one instance of '{}'
is allowed within the command. The command is executed in the
starting directory.

And that BASH programming guide is gold too.