Cmail - the author responds

[Tom Christiansen]

In article <1125 at kl-cs.UUCP> jonathan at cs.keele.ac.uk (Jonathan Knight) writes:
|Wow, I never thought that posting one little program would cause so
|much discussion.

I'd like to make sure the author doesn't take any offense about
my posting a perl translation of his program.  Perhaps my remarks
were too strong when I said something on the order of "sigh.  yet
another sysadmin widget written in long arduous C code instead of perl."
I don't want to discourage *anyone* from posting to alt.sources; it's
great to have a forum like this, and the more the better.   

|Perl may well be a really hip language to write cmail in.  Unfortunately
|the 20 unix machines we have here do not have Perl.  However they ALL
|have a C compiler.  

If they all have a C compiler, I'll bet they all compile perl.  Larry
Wall has gone to unbelievable lengths to accommodate different hardware
and software (OS) platforms.  If you don't have perl, I'm sure many,
many people would happily send it to you.  I certainly would, although
I don't yet have product 3.0 yet.  (I may fix this tomorrow now that 
our Internet connection has come back on line.)

|I have no idea how fast perl is.  If anyone wants
|to give a timing for the perl script on a 1800 line password file then
|I'll compare it to the C program.  

I can't time the original, because I don't have SysV regexp(3) routines,
so I wrote two *very* basic programs.  Here is the C version:

    main() {
	int i;
	setpwent();
	while (getpwent()) i++;
	endpwent();
	printf ("retrieved %d entries\n", i);
    } 

and here is the perl version:

    setpwent;
    while (($name, $passwd, $uid, $gid, $quota, $comment,
	     $gcos, $dir, $shell) = getpwent) { $i++; } 
    endpwent;
    printf "retrieved %d entries\n", $i;

The timing results on a passwd file of 1244 entries is:

	c version:	0.41u 0.06s 0:01 
	perl version:	1.16u 0.12s 0:02

Certainly the perl version runs more slowly.  But not very much; 
certainly not enough to dissuade me from using it.

|For now the best languages to write
|programs in if you want them to run on the largest number of unix machines
|is C or the Bourne shell and certainly NOT perl 3.0 which hasn't been
|posted yet.

It's making its way through the comp.sources.unix queue, and is available
over both UUCP and the Internet by automated retrieval.

|Someone suggested that the Bourne shell would be a good language.  I
|felt that it would take too long to process a 1800 line password
|file using /bin/sh.  If you think different then have a go.

I concur entirely.

|Someone also complained 

'Twas I.

|that I used getpwent() to read the password
|file which was inefficient.  The reason for this was that some of the
|hosts around here run Yellow Pages and so I needed to make sure that
|cmail would run on those hosts.  Getpwent() would work on all flavours
|of Unix at this site whether SYS V, BSD or BSD with yellow pages.  So
|that was the easiest thing to use.  Cmail takes 1.5 seconds to run
|on a password file of 1800 lines so I felt that it was acceptable.

What I meant was that reading *every line* was less efficient than
doing readdir()s and then getpwnam()s to check the mailboxes if 
they matched the rexprs.  I'm overly familiar with the YP problem.
I'm also curious what other people get for timings on both cmail 
and on my mini-programs.  

|The comparison of size of code isn't really fair.  Firstly my code
|had comments.  Secondly I wrote the code to be readable, not to
|be short.  Thirdly the perl code doesn't cope with the various
|GECOS field styles.  No doubt both programs could be shortened,
|but does it really matter?  I can't read perl, so I can't compare
|the readability.

That's all true.  Perl is pretty easy to read, though, if you know sed
and C.  You'd get used to it.

|Anyway, I like it as it is.

Good.  I do wonder: how long did it take you to write and debug it?  
I'm sure I did the perl version in well under a half-hour.

--tom

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