Cmail - check to see who's read their mail - UNIX

[Tom Christiansen]

In article <936 at rodan.cs.utexas.edu> steveb at cs.utexas.edu (Steve Benz) writes:
>Yes, but FACE could have been written in twisty Perl code just the same.
>While I wouldn't want to spend my life programming in the Bourne shell,
>somebody's going to have to stand up and point out that it's not all that
>much worse than Perl, especially for the Cmail application.  In fact, I
>suspect that it'd be just a wee bit nicer if written in the Bourne shell
>(with judicious use of find(1), of course.)

I, for one, will stand up and boldly state that I think the Bourne shell
*is* indeed all that much worse than perl.  Remembering that the only
standard Bourne shell you can write in is the one without functions, it
remains a poor choice for a programming language.  You have no subroutines
or associative arrays, the full range of C operators is missing, you have
to call things like grep, awk, and sed to do any real work for you.  Have
you ever tried to figure out whether stdin or stdout were ttys in a shell
script, or wished you had the full range of math intrinsics, or would have
sold your soul for printf without calling awk, or wanted to retrieve just
one character from a file or reposition that file's seek pointer?  Didn't
you ever curse the very limited regular expressions offered by grep and
sed and awk that don't even include a + operator of the {m,n} notation or
tire of writing things like [^0-9] when \D would have been easier or
writing [A-Za-z_] for \w?  Did you ever try printing out nice, paginated
reports using awk?  Haven't you ever notice that any shell script of at
least moderate complexity requires calling several times each things like
tr, sed, grep, awk, or sort?  What about if you have to pass parameters
into your awk or sed script that came in on the command line?  This is
quite unpleasant although doable.  Have you ever tried trapping signals
greater than the original v7 set?  Not all Bourne shells do so.  Didn't
you ever wish that the nawk program were available everywhere as awk so 
you could have those nifty function calls it offers you?  Have you
ever wanted a shell script to fork and feed half of it feed the other half
some data?  Bourne shell is really not an equivalent language to perl, any
more than BASIC is equivalent to C.  The *sole* thing it as going for it
is availability, and since perl is freely available for more architectures
than you ever dreamt existed, I see no reason not to use it.  A shell
script converted into perl is much faster to execute and easier to
maintain, because you no longer have to go through nearly obscene
convolutions to do easy things.  A C program written in perl will usually
(but not always!) run slower, but it will require a small fraction of
code, which speeds up development and debugging time many times.

>The point I munged in my previous post was that since it's not installed
>on all machines, and not necessarily known by the system administrators at
>those sights which have it, that perhaps it wasn't the ideal choice of
>language (though it's a damn sight better choice than C.)

Ah, you concur that perl is a damn sight better than C.  If people don't
have perl, then writing things in perl is apt to prod those people on 
to acquiring perl.  Also, are you reading this with rn, or are you using
one of those less configurable newsreaders, like vnews or nn?  If you're
using rn, as I believe much if not most of the net is doing, then what
happens when you want the next version?  It probably isn't going to happen
Real Soon Now, but its author intends to write the next version of rn 
in perl.  Thus you'll *have* to run perl to run rn.  It's like the argument
of not sending out complex patches because not everyone has patch.  Well, why
don't they?  It's free and widely available, and it makes our lives a whole
lot easier, just like rn and perl, which interestingly enough were all written 
by the same author.

/* END ADVERTISEMENT :-) */

--tom

    Tom Christiansen                       {uunet,uiucdcs,sun}!convex!tchrist 
    Convex Computer Corporation                            tchrist at convex.COM
		 "EMACS belongs in <sys/errno.h>: Editor too big!"