Simpler Navigation for Servers and Operating Systems - Please Update Your Bookmarks
Completed: a much simpler Servers and Operating Systems section of the Community. We combined many of the older boards, so you won't have to click through so many levels to get at the information you need. Check the consolidated boards here as many sub-forums are now single boards.
If you have bookmarked forums or discussion boards in Servers and Operating Systems, we suggest you check and update them as needed.
Showing results for 
Search instead for 
Did you mean: 

Perl Programming

Go to solution
Leslie Fischer
Frequent Advisor

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

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.
*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:
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

Advantages of Perl

Disadvantages of Command Shells:

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:

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

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

from wikipedia:
read about pro's and con's

read the shell scripting Capabilities & Disadvantages
Be Tomorrow, Today.
Respected Contributor

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 ]

Be Tomorrow, Today.
A. Clay Stephenson
Acclaimed Contributor

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.
Rodney Hills
Honored Contributor

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...


-- Rod Hills
There be dragons...
Leslie Fischer
Frequent Advisor

Re: Perl Programming

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

Leslie Fischer
Frequent Advisor

Re: Perl Programming

James R. Ferguson
Acclaimed Contributor

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.


H.Merijn Brand (procura
Honored Contributor

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
dirk dierickx
Honored Contributor

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

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:
Be Tomorrow, Today.