Re: perl and shell

Be careful of passing parameters with no checks. For example, a simple way might be:

my $status = system ("fred.bash @ARGV");
[download]

then someone calls it like this:

$ myscript.pl 'Program Files'
[download]

and two arguments get passed. You also have a problem if the arguments contain shell meta-characters like quotes, $, or ! in the data, which must be 'escaped' before passing. So you end up having to do something like this before calling system:

for (@ARGV) {$_ = "\Q$_\E"}
[download]

My point is that you should not blindly throw data from Perl to the shell. Likewise when using arguments in shell scripts always enclose them in double quotes, including: ".\$1", although even that is not bullet proof.
You might also consider just using one language to solve your problem (Perl or Bash) rather than two. I know, sometimes we do that just to get a job done, but it is not a good long term design.

Comment on Re: perl and shell Select or Download Code

Replies are listed 'Best First'.
Re^2: perl and shell by dsheroh (Monsignor) on Jul 01, 2007 at 16:31 UTC
And then there's the problem of people calling it like this: `$ myscript.pl ' ; rm -rf ~'` [download] Blindly passing unchecked user input to a command is a very bad idea unless you know that the code will only ever be called by trusted users. Even then, checking is generally good to guard against user error. (Granted, in this simple case, the calling user can't convince it that easily to do anything that they couldn't do from the command line anyhow unless myscript.pl runs SUID or the like, but the principle remains.)	[reply] [d/l]

Replies are listed 'Best First'.

Re^2: perl and shell
by dsheroh (Monsignor) on Jul 01, 2007 at 16:31 UTC

$ myscript.pl ' ; rm -rf ~'
[download]

(Granted, in this simple case, the calling user can't convince it that easily to do anything that they couldn't do from the command line anyhow unless myscript.pl runs SUID or the like, but the principle remains.)

[reply]
[d/l]