I'm the misleading culprit here wrt the /dev/null-quoting and associated error messages - check the update in the 2nd half of
my initial comment 3 levels up; partially due to the fact that I never use -H and thus
managed to misread something just before posting.
/dev/null and quoting: Marooned it may be, redirect it isn't :)
> I don't think you should be escaping the variables inside the backticks. They need to interpolate.
Wrong.
<insert pet-peeve alert spoiler warning>
(the following is a bit Unixish, but when I see grep, I think I'm safe enough to assume cygwin or better)
NOT INTERPOLATING is exactly the idea here to make the grep invocation secure regardless
of what kind of stupid filenames or interesting regexes appear:
Think about the full set of (pathological) filenames that can be matched with e.g. <*.vdx>;, then about regexes, and finally:
Place the variable into the environment and push
the variable interpolation into the shell. The shell now interpolates the variables, but the quotes stop the shell from doing word splitting or worse.
Better yet, by not interpolating the variable into the commandline with Perl before
exec'ing the shell due to system("grep ..."), the shell cannot see the characters in the filename/regex as shell special characters to act upon.
If you think you can protect your command arguments with just a set of quotes around filename or regex, do think about quotes, newlines(!yes!) and semicolons in the filename. Now puzzle out what the shell actually sees as commandline and as command arguments. If still in doubt, check out the link I mentioned at the top of my previous comment for the bigger picture.
And if you think your filenames are well-controlled, sane and thus don't require caution, you've still to
take care of the POSIX basic regex argument, in case the grep should ever match more than just alphanumerics.
cu,
Peter
| 