[Pdx-pm] sanity check: how to use system()

Austin Schutz tex at off.org
Mon Feb 28 22:16:54 PST 2005


On Tue, Mar 01, 2005 at 12:03:34AM -0600, Eric Wilhelm wrote:
> What's the deal with this bit of code:
> 
>   unless(system(join ' ', @command) == 0) ...
> 
> ?!
> 
> I've been digging through a lot of backup programs this week and have 
> been driven at-least-insane by the number of times that I've seen 
> something like $cmd .= $options;  system($cmd).  Particularly, this one 
> makes me really have to hope that $dir and $count are never both equal 
> to "/"
> 
>   system("$rm -rf $dir.$count")
> 
> I've checked "perldoc -f system | head -1" several times today and it 
> still says:
> 
>   system LIST
> 
> And further down, there's lots of yummy detail about how calling it with 
> a single scalar fires-up a shell and hands-off the command rather than 
> the more efficient and less-subject-to-interpolation direct hand-off to 
> execvp().  So, I'm evaluating these programs that are going to be run 
> as root and keep having to wonder if they've caught all of the corner 
> cases of special characters, spaces in filenames, and other such 
> things.
> 
> Then, I come across the above needless join of a perfectly LISTlike 
> @command and I think I surely must have lost it.  Is there a historical 
> reason or something here that I'm missing?
> 

	It is often useful to have the shell do interpolation, such
as system("rm $args") you can pass '-rf mydirectory', which will recursively
remove 'mydirectory', versus thinking the entire '-rf mydirectory' string
is an option.
	Often in modules it's easier to just pass it to the shell and let
it sort it out rather than assuming that your users will think to use it
the other way. Also it's often assumed a variable is ok as passed - you
get plenty of rope. As you say, there is a performance penalty for execing
the shell (though not usually very muh of a penalty). In some cases that
penalty matters a bit.
	Most of us probably run code in places where we aren't so concerned
with the local users being malicious.

	when in doubt run your script with -T if you are enabling other
users to run root stuff, then sanitize everything perl gripes about, then
if you are feeling brave, turn -T back off.

	Austin


More information about the Pdx-pm-list mailing list