In several prior commits in this PR we addressed the instances in our
shell test suite where we used the grep(1) command with the invalid
assumption that the command would fail if one of its input lines matched
the pattern provided with the -v option.
We corrected those use cases by revising them to use the -c option of
the "grep" command rather than the -v option, and then checking that the
number of lines the command finds which match the given pattern is zero.
As described in our prior commits in this PR, we already use this idiom
throughout many of our other test scripts, in part because it has several
advantages over other possible techniques for ensuring that the input to
the "grep" command contains no lines matching a certain pattern. In
particular, if the "grep" command were to fail with an error, it would
not output an integer count value, which would cause the test to fail.
In the majority of these existing instances where we already use the
"grep" command with its -c option, we check the line count value the
command outputs using the -eq shell test operator, since we expect
both operands to be integers.
In some cases, though, we use the "=" shell test operator to check the
line count value output by the "grep" command and its -c option. We
now revise those instances and replace the "=" comparison operator with
the -eq operator. We also remove the quotation marks around the integers
used in the comparisons, as they are unnecessary.
As well, we reorder some of the enclosing "[" shell test builtin
expressions so that the expected line count value always appears as the
first operand, and in two cases we reorder the arguments of the "grep"
command so we place the -c option ahead of the pattern to be matched.
These changes help bring the tests where we already use the "grep"
command's -c option into alignment with the many other similar instances
throughout our test suite that we have revised or corrected in prior
commits in this PR.