depends on the task spyghost - if you look at something and a Perl solution occurs to you, use Perl - if you look at something and a shell solution occurs to you, use the shell. Unless an AWK solution comes to mind of course, you should use Perl then
shell scripting can require much more time & cpu resources than awk or perl. e.g, shell:
grep my_file|sed 's/........
requires *nix to fork/exec 2 new processes to execute these utilities.
Doing comparable operations in awk or perl will use only the original process.
If there any looping constructs, shell will re-interpret the script code and repeat the fork/exec's. Perl (& awk?) has 1 compilation pass and then uses an internal byte code, presumably more efficient than re-interpret'ing.
Of course, if your script has no/little looping and/or is not heavily used, there will probably not be measurable difference between an S,P, or A implementation.
I work in a large organisation with a significant number of servers and a significant number of Admins with differing skill sets. I can assume that anyone with root access will have sufficient skills to understand a shell script but I can't assume that they know perl. This means that shell scripts have a much lower maintenance cost. I ballance this against perl's power and flexibility. My (flexible) rule of thumb is to use shell scripts unless I need the power of perl. To give examples the nightly housekeeping cron jobs
Code:
find / -name core -exec rm {} \;
will always be in shell script. The routine which analyses the sudo log file and e-mails the results to the security team is an obvious perl script. Yes I could have done it in awk but that would have been as difficult for the newbie as a perl script.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.