Recursive bash function vs iterative "eval" string building: Which performs better? - bash

Question

I am creating this function to make multiple grep's over every line of a file. I run it as following:
cat file.txt | agrep string1 string2 ... stringN
The idea is to print every line that contains all the strings: string1, string2, ..., stringN, I followed this two approaches the fist is a recursive method :
agrep () {
if [ $# = 0 ]; then
cat
else
pattern="$1"
shift
grep -e "$pattern" | agrep "$#"
fi
}
by the other hand I have a second approach related with an iterative method, since i am using a for method :
function agrep () {
for a in $#; do
cmd+=" | grep '$a'";
done ;
while read line ; do
eval "echo "\'"$line"\'" $cmd";
done;
}
This two approaches works very well but i would like to know if someone can tell me which one is the more efficient? and also if it's posible if there is a way to measure this in bash?, since i consider that i don't have the enough experience to determine this because i don't know if bash it's a programming language that works better with iterative methods or recursive methods or maybe if it's to expensive to use eval.
This two functions are designed to work with large texts and process every line of the texts, I really would appreciate any explanation or advice of this.
This is an example of text file called risk:
1960’s. Until the 1990’s it was a purely theoretical analysis of the
problem of function estimation from a given collection of data.
In the middle of the 1990’s new types of learning algorithms
(called support vector machines) based on the developed t
and then if i run:
cat risk | agrep Until
I get:
1960.s. Until the 1990.s it was a purely theoretical analysis of the
but by the other hand if i run:
cat risk | agrep Until new
prints nothing since there inst any line with that two strings, this was a function designed to clarify the usage of the function.

Answer 1

I completely agree with the comments and answers that have already informed you of the pitfalls of your current approach.
Based on the suggestion made by karakfa, I would suggest using a function that calls awk, along these lines:
agrep() {
awk 'BEGIN {
# read command line arguments and unset them
for (i = 1; i < ARGC; ++i) {
strings[i] = ARGV[i]
ARGV[i] = ""
}
}
{
for (i in strings) {
# if the line does not match, skip it
if ($0 !~ strings[i]) next
}
# print remaining lines
print
}' "$#"
}
This passes in all of the arguments to the function as arguments to awk, which would normally treat them as filenames. Each argument is added to a new array, strings and removed from ARGV before any lines of input are processed.
Use it like this:
agrep string1 string2 string3 < file

Answer 2

both are inefficient but since grep is very fast you may not be noticing. A better approach is switching to awk
awk '/string1/ && /string2/ && ... && /stringN/' file
will do the same in one iteration.

Answer 3

Security
The eval-based approach has a critical flaw: It allows code injection via maliciously formed strings being searched for. Thus, for the two as-given, the recursive approach is the only reasonable option for real-world production scenarios.
Why is the eval approach insecure? Look at this code for a moment:
cmd+=" | grep '$a'";
What happens if a=$'\'"$(rm -rf ~)"\''?
A corrected implementation might modify this line to read as follows:
printf -v cmd '%s | grep -e %q' "$cmd" "$a"
Performance
Your recursive approach does all its recursing while setting up a pipeline of length proportional to the number of arguments passed to agrep. Once that pipeline has been set up, the shell itself is out of the way (all ongoing operations are performed by the grep processes), and the performance overhead is exactly identical to the performance of the pipeline itself.
Thus, for a sufficiently large input file, the performance of the setup stage becomes effectively nil, and the relevant performance difference will be that between cat and a while read loop -- which cat will handily win for inputs large enough to overcome its startup costs.