Not useful much beyond that, and may not even be good at thatĮxcept for certain starting points, but it's faster than any find There are ways around all these things,īTW, something that almost never gets mentioned but that I willįrequently use under conditions where it is appropriate is a
Pipes or blow up on funky filenames (beginning with -, or sometimes
Searching binaries if you don't want to, won't get stuck on named Horribly slow for a full filesystem search, and it's painfullyĭifficult to properly construct a pipeline that will avoid Typically, the answer is to use find, xargs, and grep. This type of question is that none of them are ever truly fast and The problem with all the reponses that invariably pop up for That also works in GNU grep and is equivalent to "-r")Įasy enough, isn't it? For those without a modern grepīut if you are on some old Unix without recursive capabilities in its grep, it gets very hard. You can also use -exclude= to search every file except the ones that match your pattern. So would:īut this of course would not (because the file with the pattern is not under "a*"): If you had a directory strucure like this:Įither invocation would search "perlinhere" looking for "perl" inside. You don't even need the -include "grep -r perl. Say you wanted to search for "perl" in only *.html files in the current directory and every subdirectory. Just add "-r" (with perhaps -include)Īnd grep will search through subdirectories. You may want to just so you really appreciate GNU grep). If you do have a modern "grep", just go do a "man grep" you don't need to read this (though
You must mean that your ancient Unix doesn't have GNU grep, right?
#Grep recursive search how to#
How to search through sub-directories whether or not your Unix has recursive (GNU) grep.
0 kommentar(er)
