Perl Programming

[Leslie Fischer]

Hi All,

As a UNIX Administrator, what are the advantages and benefits of using the Perl Scripting Language verses using POSIX-shell Scripting to do the same things (if possible)?
Any disadvantages?

Would you recommend that an Unix Administrator learn to use Perl? Why?


Appreciate your feedback or comments. Thanks.

[inventsekar_1 · Accepted solution]

Leslie Fischer,
Really a big topic.
As per my knowledge, perl is good for new UNIX admins and shell is good for advanced UNIX admins.
HOW?
*perl scripting is like c programming.
*Perl is implemented on a wide variety of platforms
*A large number of UNIX tools was integrated into the Perl language. In some cases even with more or less the original syntax
(its like, using grep to search in c programming.)

and i think, shell will be good for advanced scripting.

and from google search:
Advantages of Perl:
http://www.cs.rit.edu/~afb/20013/plc/slides/perlintro-04.html
Perl and a huge collection of Perl modules are free software (either GNU General Public License or Artistic License).

Perl runs on all platforms and is far more portable than other environments. Perl/Tk applications or CGI scripts in Perl can be ported between UNIX and Microsoft Windows without any modifications at all.

A large number of UNIX tools was integrated into the Perl language. In some cases even with more or less the original syntax

Disadvantages of Perl
http://www.cs.rit.edu/~afb/20013/plc/slides/perlintro-07.html

Advantages of Perl
http://www.cs.rit.edu/~afb/20013/plc/slides/perlintro-04.html

==============================
Disadvantages of Command Shells:
http://www.cs.rit.edu/~afb/20013/plc/slides/perlintro-02.html

Shell scripts (be it the Bourne shell, csh, ksh, or bash) are practical as long they are very small. Longer shell scripts can no longer be easily read or maintained.

Shell scripts derive their power from other commands which run in separate processes. This applies even (at least for the classic Bourne shell) for simple arithmetic or string operations:

i=1
while [ $i -lt 10 ]
do ...
i=`expr $i + 1`
done

It is no surprise that such scripts are very slow and consume a lot of resources.

Advanced shell scripts cannot be ported easily to other systems due to the large number of external commands.


Disadvantages of awk
http://www.cs.rit.edu/~afb/20013/plc/slides/perlintro.html

from wikipedia:
read about pro's and con's
http://en.wikipedia.org/wiki/Perl

read the shell scripting Capabilities & Disadvantages
http://en.wikipedia.org/wiki/Shell_script

[inventsekar_1]

and one more interesting discussion(attachment contains the full discussion):
A Real Example:
In order to illustrate the different programming styles between the two languages DDS is including as an example a program written to solve a real problem: finding duplicate files in a directory hierarchy. Initially written as a shell script, the correct number of escape backslashes in a deeply nested sed command finally caused a rewrite in Perl. After the Perl program was finished, the shell script was completed in order to test the performance of both implementations.

and results:
1.) With the shell script coded in 36 lines and the Perl script in 42 both scripts are approximately the same size
2.) The Perl script executed in about half the time of the shell script (810 user and 816 system seconds for Perl versus 1672 user and 1842 system seconds for the shell script); a notable, but not dramatic performance difference.
3.) On the other hand at the peak of its execution the shell script was running 10 processes with a combined resident set size (RSS) of 4892K (probably a lot less since four and two of them shared the same text image) whereas the Perl script had an RSS of 8064K. It is also important to note that the RSS of Perl was constantly rising as entries accumulated into the associative array whereas the RSS of the shell script remained almost constant over its execution. This means that the shell script can handle much larger set sizes without running out of swap space as the Perl script might.

[ A Conversation about Perl and the Shell: Choosing the Implementation Vehicle
http://www.dmst.aueb.gr/dds/pubs/trade/1997-login-Perl/html/shperl.html ]

[A. Clay Stephenson]

Perl brings all the power of the shell, awk, grep, and sed into one tool. It's signal handling is far superior to the simple traps of the shell. Moreover Perl's regular expressions (RE's on steroids) are much more powerful than the shell's counterparts. I often find that I can do almost anything with Perl that I used to need to C to do -- and it's typically almost as fast. Perl also makes it possible to truly daemonize processes -- something that is not easy without a setsid function. I find that almost all of my newer scripting is done solely in Perl; nowadays I typically only use shell scripts for those tasks which must run in single-user mode before /usr (with its shared libraries) is mounted. You should also not overlook one of the best features of Perl: it's portability even to those operating systems of which I'm not very fond. As an illustration, I recently wrote a Perl script for DataProtector which worked equally well under an HP-UX or Win2003 Cell Server.

Perl really only has one disadvantage and that is its steeper learning curve primarily as a result of its richness of features. Another disadvantage (okay this is two) is the ability of cramming tremendous power into one or two lines of code so that the meaning may not be clear to someone having to later maintain the code. One can certainly write verbose and well-commented Perl but that somehow seems to run counter to the Perl culture.

Oh, if one likes, one can even write Perl Haiku.

[Rodney Hills]

Perl has also been called the administrators glue language. Many admin tasks require running of processes and then parsing the output of those processes. Perl makes it very easy to do both.

For instance- to summarize my lvm systems, I have a Perl script that runs the various lvm commands and parses the info, combines it together and gives me a nice 1 page summary.

Another instance- I have dozens of applications, each with their own log files that need to be maintained. This maintenance depends if it is a single large log file, or many smaller log files. In either way, I have one configuration file that specifies the location of the the log files and the rules on cleanup method (based on disk size, age of file, etc) and a perl script that uses that configuration file to do the necessary log file cleanup. This jobs is then launched nightly by cron.

Also, I usually will use Perl over shell scripting just because it is more fun...

HTH

-- Rod Hills

[Leslie Fischer]

Thank you all for your feedback. This is what I needed.

Leslie

[Leslie Fischer]

Closed

[James R. Ferguson]

Hi Leslie:

I'd add this, by way of borrowing and turning a phrase:

Perl makes hard things easy and impossible ones, doable.

Regards!

...JRF...

[H.Merijn Brand (procura]

And most important

Perl makes boring things FUN, and impossibe things interesting :)

Enjoy, Have FUN! H.Merijn [ still cannot resist the temptation ]

[dirk dierickx]

well, a few things, like speed of both execution and results (with results i mean the time it takes to come up with something that works).
perl is much more then shell scripting, just take a look at cpan to find out what is available, even in the default perl installation there is a lot of stuff included which would be very hard to do in shell scripts.
more and more you'll find perl used in commercial programs/tools. in case of problems it's nice to know perl to troubleshoot instead of waiting on support to solve it for you.
make no mistake, perl is a real programming language, that can be abused just like any other, but it also allows you to whip something small up that does a lot in a few lines of code. no need for compiling, just write and run. as a bonus you get a real good debugger with perl, which makes it easier to debug your 'scripts' then when using shell scripting.

[inventsekar_1]

still i like to post this:
HTH leslie and others too.
==========================
When not to use shell scripts


Resource-intensive tasks, especially where speed is a factor (sorting, hashing, etc.)

Procedures involving heavy-duty math operations, especially floating point arithmetic, arbitrary precision calculations, or complex numbers (use C++ or FORTRAN instead)

Cross-platform portability required (use C or Java instead)

Complex applications, where structured programming is a necessity (need type-checking of variables, function prototypes, etc.)

Mission-critical applications upon which you are betting the ranch, or the future of the company

Situations where security is important, where you need to guarantee the integrity of your system and protect against intrusion, cracking, and vandalism

Project consists of subcomponents with interlocking dependencies

Extensive file operations required (Bash is limited to serial file access, and that only in a particularly clumsy and inefficient line-by-line fashion)

Need native support for multi-dimensional arrays

Need data structures, such as linked lists or trees

Need to generate or manipulate graphics or GUIs

Need direct access to system hardware

Need port or socket I/O

Need to use libraries or interface with legacy code

Proprietary, closed-source applications (shell scripts put the source code right out in the open for all the world to see)


If any of the above applies, consider a more powerful scripting language -- perhaps Perl, Tcl, Python, Ruby -- or possibly a high-level compiled language such as C, C++, or Java. Even then, prototyping the application as a shell script might still be a useful development step.

Advanced Bash-Scripting Guide:
http://www.tldp.org/LDP/abs/html/why-shell.html