Re^3: Perl backticks and GREP?

Unquoted string "dev" may clash with future reserved word at ./nelson. +pl line 15. Unquoted string "null" may clash with future reserved word at ./nelson +.pl line 15. ... Argument "dev" isn't numeric in division (/) at ./nelson.pl line 15, < +ARGUMENTS> line 1. Argument "" isn't numeric in division (/) at ./nelson.pl line 15, <ARG +UMENTS> line 1. Illegal division by zero at ./nelson.pl line 15, <ARGUMENTS> line 1.
[download]

All of the above are generated by the /dev/null you have marooned outside the backticks. Are you attempting to redirect the output of grep?

Use of uninitialized value in scalar assignment at ./nelson.pl line 8, + <ARGUMENTS> line 1. Use of uninitialized value in scalar assignment at ./nelson.pl line 9, + <ARGUMENTS> line 1.
[download]

You don't seem to have initialised $file or $argument anywhere before trying to use them.

grep: : No such file or directory

I don't think you should be escaping the variables inside the backticks. They need to interpolate.

I hope these points help you move forward.

Cheers,

JohnGG

Comment on Re^3: Perl backticks and GREP? Select or Download Code

Replies are listed 'Best First'.
Re^4: Perl backticks and GREP? by jakobi (Pilgrim) on Oct 19, 2009 at 20:22 UTC
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	[reply] [d/l]

Replies are listed 'Best First'.

Re^4: Perl backticks and GREP?
by jakobi (Pilgrim) on Oct 19, 2009 at 20:22 UTC

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.

[reply]
[d/l]