in reply to Perl vs. Shell Script

"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

Replies are listed 'Best First'.
Re: Perl vs. Shell Script
by Abigail-II (Bishop) on Jun 21, 2002 at 18:14 UTC
    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.

    Abigail

[reply]
      ...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).

[reply]
        I do not know what you mean. "shared memory" is the common term used if processes share part of their memory - to exchange data. I've never heard of shells communicating with utilities using shared memory - for this to work shells and utilities need to cooperate.

        I guess you mean something else, but I don't know what. It's also unclear what you mean by "spawning" a process. I think most people would consider "fork + exec" to be "spawning" (assuming we're talking Unix), but since you want to do something else than "exec", it's not a typical "fork + exec" you are referring to.

        Under UNIX, there is just one way of creating a new process, and that's by using "fork". And there's only one way to start a different program, and that's by using a member of the exec family.

        Abigail

[reply]
      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

[reply]
        Well, there are (good) reasons to write shell programs. The shell is everywhere (well, at least on Unix and POSIX systems), where as Perl, Python and Ruby aren't. The production environment of the project I'm currently working on doesn't have Perl, so writing tools and utilities for that in Perl isn't an option.

        And let's not forget that to build Perl, you need to run Configure - which is a shell script.

        Abigail

[reply]

In Section Seekers of Perl Wisdom