jonathan@cs.keele.ac.uk (Jonathan Knight) (10/26/89)
Wow, I never thought that posting one little program would cause so
much discussion.
Anyway, here's my thoughts on all your talk.
Perl may well be a reall 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. 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. 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.
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.
Someone also complained 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.
As a note to the perl and Bourne shell advocates, make sure you can
use your version of cmail on hosts with yellow pages. I notice that
the perl script that was posted does use getpwent and will be able
to use yellow pages.
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.
Anyway, I like it as it is.
--
______ JANET :jonathan@uk.ac.keele.cs Jonathan Knight,
/ BITNET:jonathan%cs.kl.ac.uk@ukacrl Department of Computer Science
/ _ __ other :jonathan@cs.keele.ac.uk University of Keele, Keele,
(_/ (_) / / UUCP :...!ukc!kl-cs!jonathan Staffordshire. ST5 5BG. U.K.tchrist@convex.COM (Tom Christiansen) (10/27/89)
In article <1125@kl-cs.UUCP> jonathan@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@convex.COM "EMACS belongs in <sys/errno.h>: Editor too big!"