It’s all too easy to assume that everyone else knows what you know. We tend to take it for granted that all technical users are familiar with regexes. And also that, being familiar, we assume they also know how to use them to best advantage. This is not always the case, as a recent support call made clear. The customer wanted to restrict a particular check to a particular volume, but the problem was the check script kept checking multiple other volumes with similar names. An example will make this clearer, we try to restrict the checks to running against the single vol0 colume by using the command -I vol0:$ ./check\_netapp\_pro.pl Usage ‑o volume ‑H $HOST … ‑I vol0 ↵ Result code: OK NETAPP\_PRO USAGE OK ‑ 3 volumes checked 2 volumes skipped because of ‑‑include/‑‑exclude settings. …The script found 3 volumes to check and skipped 2. The devil is in the details. If the intention was to check all volumes with the string vol0 anywhere within their names, then this instruction is correct. However, if the intention was to restrict the checks to the single vol0 volume, as was the customer’s unfulfilled wish, then this commandline instruction is wrong. The -I (or --include) word is not a string to compare exactly with another string, rather it is a regular expression, AKA. a regex. A regex is a description of a string, possibly using multiple meta characters, to match another string. In our example above the –include switch was looking for volumes which included the vol0 string in it’s name, and found several. If we want to pin the match down, then we have various options but the simplest is to say that the vol0 is completely contained within the start and end boundaries of the volume name we’re looking for. We do this using the special meta characters ^ (start of string) and $ (end of string). Let’s try that with our example:```
$ ./check_netapp_pro.pl Usage ‑o volume ‑H $HOST … ‑I ^vol0$ ↵
Result code: OK
NETAPP_PRO USAGE OK ‑ 1 volume checked
4 volumes skipped because of ‑‑include/‑‑exclude settings.
…
Comments