I would try using a single awk (or on Solaris/SunOS systems /usr/xpg4/bin/awk or nawk) script instead of trying to compare outputs from two fgrep commands:

Code:

#!/bin/ksh
if [ $# -lt 1 ]
then	printf 'Usage: %s file...\n' "${0##*/}" >&2
	exit 1
fi
/usr/xpg4/bin/awk '
function check() {
	if(f1 && f2)
		print fn
	fn = FILENAME
	f1 = f2 = 0
}
FNR == 1 {
	check()
}
/<Orin>sop/ {
	f1 = 1
}
/<Dup>two/ {
	f2 = 1
}
END {	check()
}' "$@"

But, if you want to do it using fgrep, you could try something like:

Code:

#!/bin/ksh
if [ $# -lt 1 ]
then	printf 'Usage: %s file...\n' "${0##*/}" >&2
	exit 1
fi
fgrep -l '<Orin>sop' "$@" | sort -r > match1.$$
fgrep -l '<Dup>two' "$@" > match2.$$
fgrep -xf match1.$$ match2.$$
rm -rf match[12].$$

Note that I don't believe that the sort -r half of the pipeline with the 1st fgrep should be needed, but on some systems (including Apple OS X which uses a BSD based grep utility), the command:

Code:

fgrep -x -e pattern -e pattern2 file

will not print lines in file matching pattern2 if pattern is a string matching an initial substring of pattern2. But, if the order of those matching patterns is reversed, it correctly finds all of the matching lines. I don't know if the Solaris fgrep suffers from this issue or not, but with the sort -r, the problem should be avoided if it does exist.

Note also that the 2nd script takes fewer lines (and is 35 characters shorter), running 3 fgrep commands and an rm command (not counting the sort that might not be needed depending on how fgrep -x works on your system) will take longer to run than one invocation of awk unless you are processing LARGE files and the patterns you're looking for appear early in the files. On systems where awk includes the nextfile command, that difference could be removed, but awk, nawk, and /usr/xpg4/bin/awk on Solaris systems do not provide do not provide that extension.