ellem has asked for the wisdom of the Perl Monks concerning the following question:

Which should a person use? I do things with Perl. Not terribly interesting things but things I need done.

I don't know any Shell Scripting (I think, but maybe I do.) I don't even know what I would script if I do, in fact, know Shell Scripting. I realize it will be diff't with each Shell but I mostly only use sh and bash.

So which should I be using? Or is this a case where I need to enough Shell Scripting to get by for when Perl isn't there? Like the two text editors whose names are not to be spoken, but the one that isn't always there rhymes with a product from Apple.
There's more than one way to do it, but only some of them actually work.

Replies are listed 'Best First'.
Re: Perl vs. Shell Script
by Abigail-II (Bishop) on Jun 21, 2002 at 17:52 UTC
    It's usually a trade off. Years ago, anything that would take more than 10 lines in shell, I'd write in Perl. Nowadays, the cut-off mark is at 1 line. If I can't do it in one line of a shell command, I do it in Perl. But there are a lot of things that could be done in one line of shell I do in Perl.

    There are exceptions of course. A Bourne shell (or a superset like the Korn shell or a POSIX shell) is found on any Unix system - unlike Perl. And installing Perl isn't always an option. So, sometimes I write long complicated shell scripts. But I would prefer Perl....


Re: Perl vs. Shell Script
by talexb (Canon) on Jun 21, 2002 at 17:42 UTC
    "When you get your first hammer, everything looks like a nail"

    Like that old saw, it sure is handy to roll out Perl for everything. You need to pick up different tools when the situation dictates, however .. Perl is a complex tool, so has a large-ish memory footprint.

    For something that requires lower memory requirements and fairly simple logic, a shell script would probably be a better choice. Of course, you have to weigh that against the possibility that you'll need to add a script feature that will require language features only available in Perl.

    For something that requires maximum speed, on the other hand, you'll probably want hand-tuned C or even a mix of assembler and C.

    So the answer, it seems, is "It depends..".

    --t. alex

    "Mud, mud, glorious mud. Nothing quite like it for cooling the blood!" --Michael Flanders and Donald Swann

      Don't over estimate the smallness of the footprint of a shell. Some quick testing shows that (at least on my system), perl takes less than twice the memory of bash. And it takes less memory than bash + grep combined. One should realize that a shell might take less memory than perl, but do to something interesting in a shell, you got to use additional programs.


        ...perl takes less than twice the memory of bash.

        I suppose it depends on the system and shell, but aren't shell processes often kept in shared memory, and so additional shell processes would take little or no additional memory? I remember reading on some man page that you usually may as well spawn another process rather than use 'exec' for this (among other) reason(s).

        Indeed a shell has no meat and must rely on many executable like grep, cut, sed, awl, find, ls. Beside the cost of paging them in (and out if you are really short on memory), there is the cost of forking them. Eventually there is the problem of portability. If you want to restrain yourself to the set of options supported identically everywhere, learning this set will cost you a lot. Better learn more of perl than to learn a subset that will bind one of you arm behind your back. And I forgot, even if you don't use them the features of these various command is there, you will have to carry them as extra luggage (bigger executable).

        Except if you have to maintain existing shells, writing in Bourne shell or bash is a total loss except if people around you don't want to learn perl. But, in that case, this is not a technical limitation but a social one.

        If there is a question, it is to choose between perl, python and ruby. I think with CPAN perl is still a winner even if it shows clear signs of entropy.

        By the time ruby and python will have libraries as rich as CPAN, we will be using perl6. :)

        -- stefp -- check out TeXmacs wiki

Re: Perl vs. Shell Script
by Aristotle (Chancellor) on Jun 21, 2002 at 18:53 UTC

    The biggest point, which Abigail already made, is that there's hardly such a thing as a pure shell script. You need other Unix tools to do fancy stuff.

    That can be clumsy. find trickery often leads to spawning hundreds of processes. sed is fun since it's small and light and can get things done quick&dirty. sort is a hackjob more often than not. awk is missing the ward to complete the name and is clumsy enough that I've never really gotten to use it - I find myself moving the script to Perl sooner than I get a chance to play with awk.

    I enjoy working on the shell immensely (after 10 years of COMMAND.COM, who wouldn't?), but when scripting it depends on the complexity. The point when I abandon bash and move to Perl is when I need more than 3 or 4 calls to external tools to get the job done. Sometimes that limit is as tight as it seems, sometimes - because bash is quite powerful - it's enough. More demanding stuff is likely done better in Perl. (I saw a suite of CGI scripts for system administration once - written in bash. A very surreal experience.) Most of my scripts start out as some semicomplex command I find myself using repeatedly. When I get tired of typing, I dump the sequence into a shell script. As time goes by I find myself tweaking the script to be more generically usable. I often hit a brick wall with the shell at that point and things get really clunky. Transition to Perl is then just a logical step.

    Makeshifts last the longest.

Re: Perl vs. Shell Script
by kvale (Monsignor) on Jun 21, 2002 at 17:40 UTC
    As a data point, I used to do a lot of shell scripting, but then learned Perl. Now I do all the shell stuff in perl instead. I find it a much more powerful and pleasant language than sh or bash. The only shell programming I do nowadays is setup of my personal environment.

Re: Perl vs. Shell Script
by BazB (Priest) on Jun 21, 2002 at 17:44 UTC

    All depends on what you want to do, and how complex said task is likely to become in future.
    I prefer to script larger projects in perl, rather than shell.
    I use Perl where I can, but some things are just as easy, if not easier, with a couple of UNIX commands strung together in a shell script, or on the commandline.

    There's more than one way to do it, and that one way might just be shell.

    It's probably good to have enough of a clue how to script basic things. Sometimes, you might even end up mixing perl with shell, nasty though that may be, :-)


Re: Perl vs. Shell Script
by bronto (Priest) on Jun 22, 2002 at 10:42 UTC

    I think that knowing at least a little of some shell, sed and awk with perl reveals itself quite useful. You can do with perl everything you would do in the shell, I believe, but somethimes using the shell alone or coupling it with perl makes things simpler and/or faster. I'll try to show that with a few examples.

    Whatching a log running, removing some unuseful lines and cleaning up others: here I prefer the shell, with tail and sed:

    tail -f /logs/mail.log | sed -e '/last message repeated/d' -e 's/messa +ge forwarded from myhost: //i'

    In a multiple-machine syslog, show only messages coming from a single host: awk can do the trick easily:

    tail -f /logs/mail.log | awk '$4~/host/ { print }'

    Read output from uptime and play a sound if load level in the last 5 seconds is lower than 0.4: here you can make the shell (bash) play with perl:

    (while true ; do uptime ; sleep 3 ; done) | perl -ne '@load = /\d\.\d +\d/g ; print "\a" if $load[0] < .4 ; print "@load\n"'

    but you could easily do the same using perl alone and backticks.

    Summing up: you can make it knowing just perl, but knowing a good perl with a little of a shell and some basics of common unix tools can make your life easier.

    My 2 cents (of Euro :-)

Re: Perl vs. Shell Script
by traveler (Parson) on Jun 21, 2002 at 20:59 UTC
    This was discussed a few months ago with regards to ksh, but you might find some of the arguments similar. You can find my comments here. The whole thread is here. The discussion was IMHO interesting.

    HTH, --traveler

Re: Perl vs. Shell Script
by runrig (Abbot) on Jun 21, 2002 at 21:09 UTC
    When I want to know if the fifth field of some data is greater than 500000, then nothing beats awk '$5 > 500000', but if it gets more complicated than that, I'll probably move to perl. Usually if the script mostly just needs to call system commands, I'll do it in shell, but maybe not depending on how I'm processing the input or output of those commands.

    Is that at all useful?

Re: Perl vs. Shell Script
by hacker (Priest) on Jun 22, 2002 at 10:44 UTC
    I'm surprised nobody has suggested using The Perl Shell, psh.
    "The Perl Shell (psh) is a shell that combines the interactive nature of a Unix shell with the power of Perl. The goal is to eventually have a full featured shell that behaves as expected for normal shell activity. But, the Perl Shell will use Perl syntax and functionality for control-flow statements and other things."
      There are currently two problems that preclude perl to take off as an interactive shell. The grammar and the scoped eval.

      The current grammar of Perl5 makes perl as interactive shell irrealistic. An interactive shell uses a lot of string literals that must be quoted in Perl which is very impractical. That problem will be solved by the ability to dynamically tailor the perl6 syntax. There is no doubt that a syntax for interactive use will emerge: redirection and pipe will be expressed more shortly than comparaison and bitwise or. We call that "Huffman coding". Currently attempts (filter, preprocessor...) to build an interactive shell from perl can only be hacks.

      The second problem is the current behavior is the amnesic eval which against granular interaction that is the basis of interactivity. Indeed each line must be evaluated but the amnesic eval force the user to type unacceptable long lines. I explained te problem in RFC 351: Beyond the amnesic eval but the grammatical hack I proposed does not fit in Perl6 syntax.

      Anyway, if I read correctly the apocalypse and exegesis. try { } will be the Perl6 equivalent of the Perl5  eval {  }. I hope that the string eval eval "" which is not braced will be unscoped in Perl6. This seems consistent with the general principles stated for Perl6 syntax

      These 2 problems solved, I see no raison that Perl6 won't eventually become the prevalent interactive shell.

      -- stefp -- check out TeXmacs wiki

Re: Perl vs. Shell Script
by greenFox (Vicar) on Jun 22, 2002 at 14:56 UTC

    I have a rule which I try to keep in mind- "don't use Perl for what you can do simply with sh or sed or awk or <insert shell tool> and don't use sh and sed and awk and <insert shell tool> for what can be done simply in Perl".

    As I have matured in both environments I have found the scope of what I can do simply/elegantly with each has increased. Perl's has a distinct unix heritage, any time you invest in learning shell will not be wasted when you come back to Perl.

    my $chainsaw = 'Perl';

Re: Perl vs. Shell Script
by data64 (Chaplain) on Jun 21, 2002 at 21:18 UTC
Re: Perl vs. Shell Script
by FoxtrotUniform (Prior) on Jun 22, 2002 at 22:40 UTC
Re: Perl vs. Shell Script
by rbc (Curate) on Jun 22, 2002 at 02:40 UTC
    You should use shell if it is a short script and you do not plan to port it to another OS.
Re: Perl vs. Shell Script
by Anonymous Monk on Jun 22, 2002 at 02:34 UTC
    *sigh* Evem though some cs-academic types might argue perl is not a programming language according to some bs cs test, perl is a programming language. bash is not (at least not a useful one). If you're even considering sh or bash, just go ahead and use perl4 or even BrainFuck (it's exists).