http://www.perlmonks.org?node_id=668642


in reply to Unix shell versus Perl

I decided to learn Perl because I was unsatisfied by what I could achieve with batch and shell scripting. Granted, I knew only a little shell scripting, but I did a lot of batch scripting. In particular, flow control and error checking are difficult and verbose in a batch script. Also, there are too many things that you just can't do without firing up a C compiler and writing a utility or searching for a ported unix tool. The unix shells are better off, since one rarely needs to hack up a custom tool, but one needs to learn awk and sed and find and a thousand other little programs to do really cool stuff. Perl's portability is key.

The other thing that sold me on Perl over batch/shell scripting, is Perl's flexibility--once I built expertise in Perl, I knew I could apply it for many things other than the original problems I was trying to solve. Since you've already got a lot of Perl in your environment, using it in place of batch and shell will "deepen your bench"--more people will have and use skills that apply across your environment.

As to reasons to write something in a shell or batch file, I wouldn't go for a checklist. I'd say simply that "Everything should be written in Perl unless there is a compelling reason to do otherwise." Too often I've "known" that something need not be portable or will always be small, only to be proven wrong. Neither "it doesn't need to be portable", "it's really short" are reasons to write a batch or shell script instead of Perl. If either condition is false, there needs to be a very strong argument to go with a batch/shell solution over Perl.


TGI says moo