Shell Programming and Scripting

You could also try using awk. If the output order doesn't matter, try:

Code:

awk '
FNR == NR {
	k[$0]
	next
}
$0 in k {
	k[$0]++
}
END {	for(key in k)
		if(k[key] > 1)
			print key, k[key]
}' fileA.txt *multfiles.txt

which, with the awk on my system and the sample files you provided, produces the output:

Code:

25.2292,-80.8542,29.1 2
25.2292,-80.8958,29.2 3

but the order of the output lines may vary with different versions of awk.

If the order of the output has to match the order of the entries found in fileA.txt (as in your sample output):

Code:

awk '
FNR == NR {
	k[$0]
	o[++oc] = $0
	next
}
$0 in k {
	k[$0]++
}
END {	for(i = 1; i <= oc; i++)
		if(k[o[i]] > 1)
			print o[i], k[o[i]]
}' fileA.txt *multfiles.txt

which should produce the output:

Code:

25.2292,-80.8958,29.2 3
25.2292,-80.8542,29.1 2

on any system.

If you want to try this on a Solaris/SunOS system, change awk to /usr/xpg4/bin/awk or nawk.


===========
Sorry, it looks like the 1st suggestion is a late repeat of other suggestions. I won't delete this post in case being able to produce output in the same order as the output produced by the original script in post #1 is desirable.

No this doesn't work, even if \; or + is added, because the output is on multiple lines.
Perhaps a string match (a . is a . not any character) ext=$(fgrep -xhc "$line" *multfiles.txt | wc -l) is more exact (but still slow).

Note: if you perform measurements, remember to either clear the cache with each run, or execute the command twice and take the second value, to create similar circumstances and so that the various methods are comparable..

I find it hard to believe that #5 and #6 would vary at all, they are essentially the same code. It is possible that #6 was timed first and that caching/buffering allowed #5 to avoid a lot of disk IO.

Edit: Didn't seen Scrutinizer's post before adding this - still worth stating the 5&6 shouldn't vary anywhere near the amount indicated by the testing.