Carlos E. R. wrote:
Didn't know there was a named pipe in there :-)
Whenever I grep for something or other, I virtually always use the "find <specification> | xargs grep" combination. The xargs can also be parallelized, a big advantage if you've got multiple cores and many files.
Ah, I did not know that, either.
But it is not automatic, you have to tell it how many jobs and when you do, it defaults to 1 command / process unless you tell it otherwise. Also, unless you have a slow-search expression, grep will usually be disk bound not cpu bound -- so spawning off extra copies to do simultaneous reads on different files isn't likely to give you as much increased benefit as you'd like... As an example, I have a script that runs an rpm query on every rpm in a directory to gather information.... As a result, I found that after about 9 Q's, I started losing overall speed -- that's 9 cpu's each running 1/9th of the list. Overall cpu usage for the job is about 300%, so 6 of those cpu's were waiting on disk -- not very efficient, but overall 9 Q's was best for this particular 'job'.....that's partly because the disk it was doing the queries on is a RAID50. If it was a single disk, probably no more than 3Q's before disk thrashing slows down overall progress... Anyway, if you set your GREP_OPTIONS="-D skip --binary-files=without-match" in your bashrc, grep will generally be better behaved... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org