Re: Perl Programming (314 Views)
Reply
Frequent Advisor
Leslie Fischer
Posts: 72
Registered: ‎09-05-1997
Message 1 of 11 (314 Views)
Accepted Solution

Perl Programming

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.
Respected Contributor
inventsekar_1
Posts: 508
Registered: ‎01-30-2006
Message 2 of 11 (314 Views)

Re: Perl Programming

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
Be Tomorrow, Today.
Respected Contributor
inventsekar_1
Posts: 508
Registered: ‎01-30-2006
Message 3 of 11 (314 Views)

Re: Perl Programming

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 ]

Be Tomorrow, Today.
Acclaimed Contributor
A. Clay Stephenson
Posts: 17,825
Registered: ‎07-16-1998
Message 4 of 11 (314 Views)

Re: Perl Programming

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.
If it ain't broke, I can fix that.
Honored Contributor
Rodney Hills
Posts: 1,679
Registered: ‎09-09-1996
Message 5 of 11 (314 Views)

Re: Perl Programming

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
There be dragons...
Frequent Advisor
Leslie Fischer
Posts: 72
Registered: ‎09-05-1997
Message 6 of 11 (314 Views)

Re: Perl Programming

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

Leslie
Frequent Advisor
Leslie Fischer
Posts: 72
Registered: ‎09-05-1997
Message 7 of 11 (314 Views)

Re: Perl Programming

Closed
Acclaimed Contributor
James R. Ferguson
Posts: 21,184
Registered: ‎07-06-2000
Message 8 of 11 (314 Views)

Re: Perl Programming

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...
Honored Contributor
H.Merijn Brand (procura
Posts: 6,188
Registered: ‎10-13-1997
Message 9 of 11 (314 Views)

Re: Perl Programming

And most important

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

Enjoy, Have FUN! H.Merijn [ still cannot resist the temptation ]
Enjoy, Have FUN! H.Merijn
Honored Contributor
dirk dierickx
Posts: 958
Registered: ‎12-20-1999
Message 10 of 11 (314 Views)

Re: Perl Programming

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.
Respected Contributor
inventsekar_1
Posts: 508
Registered: ‎01-30-2006
Message 11 of 11 (314 Views)

Re: Perl Programming

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
Be Tomorrow, Today.
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.