06-13-2006 10:08 AM
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)?
Would you recommend that an Unix Administrator learn to use Perl? Why?
Appreciate your feedback or comments. Thanks.
Solved! Go to Solution.
06-13-2006 12:42 PM
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 ]
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
read about pro's and con's
read the shell scripting Capabilities & Disadvantages
06-13-2006 12:47 PM
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.
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
06-13-2006 12:47 PM
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.
06-14-2006 02:37 AM
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
06-14-2006 06:21 PM
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.
06-26-2006 07:14 PM
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: