>>>>> "Gregory" == Gregory L Hansen <glhansen@steel.ucs.indiana.edu> writes:

Gregory> I actually have some familiarity with shells, less now
Gregory> than I did through disuse of most features besides
Gregory> starting up programs and sometimes piping them around.

Familiarity with shell (interactive commands) is not familiarity with
shell programs. People seldom use variables on the interactive
commands, but they're sort of indispensable when writing shell
scripts. Although I also use 'while' and 'for' loops occasionally in
an interactive command line, I think I'm an exception. Most people
using the command line won't go that far. But loops are very often
seen in shell script programs.


Gregory> And I know C and C++, but I haven't used them much in a
Gregory> Unix context.

There shouldn't be much difference. They syntax is the same. The
semantics (of function calls in stdlib, stdio, etc.) is the same.
Only the OS-dependent parts needs some adjustments. That's a
relatively simple thing.


Gregory> And I have a fat Unix book that describes some of that
Gregory> stuff, like sed and awk but not Perl, that I plan to go
Gregory> through when I get Linux in my home.

Go ahead. As I mentioned in another posting, it is the *concepts*
that you learn from these tools that is more important. You reuse
these concepts when you learn Perl.


Gregory> But Perl has been described as doing more than sed and
Gregory> awk together,

Yes. sed and awk are very simple tools. I'm not sure if they're even
Turing complete. Perl, OTOH, is Turing complete.


Gregory> removing the need to pipe things around between the two
Gregory> and the shell,

No. When you need to tie two programs together as in
ls -lR / | mail 007@spy.com
You still need to make pipes and start the two programs (or you
delegate this task to a system() command).

But I know what you mean. Shell is relatively retarded: it doesn't
have many built-in commands. It relies a lot on "external" commands.
Even 'test' and 'expr' and 'bin' are external! (I'm talking about
/bin/sh, not bash.) The advantage is that the language remains very
simple. The cons are that even simple and frequent operations like
'test' needs to be done by an external program, requiring a fork() and
using pipes to fetch the results. Perl avoids this by providing a
very right set of built-in functions and add-on modules (see also
CPAN). In most cases, you can do a lot using Perl commands without
invoking an external program. That saves the fork() call and the
overhead of pipes.



Gregory> so I wondered whether I even need to care about them.

You shouldn't. Shell scripts are meant to be used to combine existing
commands together to do something useful. Not for sophisticated
programs. (I can't understand why some people write thousand-line
long shell scripts. I can only tolerate shell scripts up to 500
lines.) Not even for efficiency. It's the fast-prototyping and quick
development that counts. This is its strength. If your shell program
suffers from bad performance (but otherwise works correctly), you
should start thinking reimplementing it in C/C++. Having a working
(though inefficient) version helps a lot when reimplementing an
efficient version.


Gregory> One thing I have in mind is a fairly elaborate e-mail
Gregory> filter that can keep tallies, filter on attachments, send
Gregory> notifications of spam deletions, recognize spoofed words
Gregory> like pe.n!s, which are things that slocal on my Sun shell
Gregory> account can't do, so off-hand Perl seemed like the one to
Gregory> use, based strictly on what I've read about it but no
Gregory> knowledge of it.

Perl seems to suit that purpose well. As mentioned before, I would
first prototype it in Perl. It's quite easy in Perl and you may be
able to come up with something working within a few days. Then, let
it run to see if it has a performance "good enough". I think it will
be that case. If not, you should evaluate how it can be improved:
where are the bottlenecks? How can it be improved (in Perl only)? Is
it better if that part (not the whole program) is implemented in C
instead? ...


Gregory> At least one person likes Python for scientific
Gregory> programming, but I don't know if that does things that
Gregory> Perl doesn't, or makes the job especially easier than C
Gregory> or Fortran would.

I can't comment about Python, as I don't know it. Given the type of
task you've mentioned, I believe it's easier to do in Perl. I choose
the language(s) to use depending on the task, not on what language(s)
I like. Using a language that suits the task saves lots of time and
energy.



--
Lee Sau Dan +Z05biGVm-(Big5) ~{@nJX6X~}(HZ)

E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee