develooper Front page | perl.perl5.porters | Postings from May 2006

Re: [perl #39011] system, exec etc unable to handle shell functions

Thread Previous | Thread Next
Dominic Dunlop
May 1, 2006 06:55
Re: [perl #39011] system, exec etc unable to handle shell functions
Message ID:
On 2006–05–01, at 01:22, Cai Qian wrote:
> It seems better to have a same behavior as AWK, or even C, so there is
> no need to  supply such  addition ; or sh -c.

There are five reasons for Perl's behaviour:

Efficiency: a direct system call in the absence of shell  
metacharacters avoids the overhead of starting a shell

Predictability: not all shells (particularly non-UNIX shells) behave  
in the same way; avoiding their use aids portability.

Diagnostics: more information is available to perl when a directly  
executed command fails than when a command executed by a sub-shell  

Flexibility: Perl gives you a choice; awk does not. (C gives you a  
choice too: use fork(), execp() or whatever instead of system() --  
but Perl's a whole lot more concise.)

Security: Because Perl gives the programmer a choice, production- 
quality code can avoid using the shell -- passing a command-line to a  
shell may allow a malicious user to insert dangerous content into  
that command-line. (Consider, for example, system("grep $string  
logfile") where a user manages to set $string to "x /dev/null;  
killall -HUP sh; : ". (See, for example, the Security chapter of  
Programming Perl for more discussion and for defences.))

The root of your problem lies in the issue of flexibility: you did  
not realise that Perl was giving you a choice -- you just wanted it  
to do what you meant, and you found a case where it didn't. Sorry  
about that, but I hope that you can see that there are good reasons  
why Perl behaves in the way that it does.
Dominic Dunlop

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About