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

Abigail

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.

Abigail

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

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.

Makeshifts last the longest.

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, :-)

BazB

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'
[download]

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 }'
[download]

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"'
[download]

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 :-)
--bronto

HTH, --traveler

Is that at all useful?

"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

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';

The thread "Comparison between Perl and Ksh" might be of interest to you.

<cite>Just a tongue-tied, twisted, earth-bound misfit. -- Pink Floyd</cite>

Depends on the task at hand. Choose the most powerful language you can, whether it's shell, Perl, Lisp, or INTERCAL.

(Uh, that INTERCAL thing was a joke.)

--
The hell with paco, vote for Erudil!
:wq