leres@ace.ee.lbl.gov (Craig Leres) (10/24/89)
> Here's a neat little program which detects whether users on your > local machine have ready their mail recently. It reports when they > last checked it and also whether any new mail has arrived since. Note that if a user is logged in and uses biff (or sysline), you can't really tell when mail was last read since biff reads new messages as they arrive. This is particuarly a problem if the person stays logged into a workstation 24 hours a day... Craig
tchrist@convex.COM (Tom Christiansen) (10/24/89)
In article <4006@helios.ee.lbl.gov>, leres@helios.ee.lbl.gov (Craig Leres) writes: >Note that if a user is logged in and uses biff (or sysline), you can't >really tell when mail was last read since biff reads new messages as >they arrive. This is particuarly a problem if the person stays logged >into a workstation 24 hours a day... Only if your vendor hasn't fixed biff(1) to save the st_atime from when it stats the file and restore it with utimes(2) after you're done reading. Once this is done, your shell can do this on login: if ($st_size) { printf "You have %s mail.\n", $st_atime > $st_mtime ? "old" : "new"; } oops, that was in perl not C :-) (i just wrote the perl translation to cmail and posted it to alt.sources) you see what i mean though. --tom Tom Christiansen {uunet,uiucdcs,sun}!convex!tchrist Convex Computer Corporation tchrist@convex.COM "EMACS belongs in <sys/errno.h>: Editor too big!"
steveb@cs.utexas.edu (Steve Benz) (10/25/89)
tchrist@convex.COM (Tom Christiansen) writes: [ In response to the people-who-don't-read-mail-checker ] > >Sigh. Yet another piece of system administrative hackery written in C... >it seems like terrific overkill >to do this in C. So as an exercise, I rewrote the program in perl (version >3.0). While I certainly find your program preferable to the original, I question your choice of Perl instead of a shell script. Granted, your Perl program would be faster on some systems, but (at the risk of making a baseless assertion) the Bourne shell is the standard language for writing administrative hackery. >...Two comments on the >original C code: doing getpwent()s until you run out is terribly innefficient >on systems with long passwd files; mine is ~1300 lines long, and it would be >better to do readdir()s on SPOOL and then getpwnam()s on the results. Yes, but don't be so sure that: - There aren't multiple spool directories--a common situation where workstations are involved. - There even is a spool directory at all--The new mail system here (& many other sites, I believe) keeps mailboxes in the home directory of the user. - Steve
tale@pawl.rpi.edu (David C Lawrence) (10/25/89)
In <932@lego.cs.utexas.edu> steveb@cs.utexas.edu (Steve Benz) writes:
Steve> While I certainly find your program preferable to the original,
Steve> I question your choice of Perl instead of a shell script.
Steve> Granted, your Perl program would be faster on some systems, but
Steve> (at the risk of making a baseless assertion) the Bourne shell is
Steve> the standard language for writing administrative hackery.
And ForTran used to be the standard language for writing just about
anything that added two or more numbers. And cards used to be the
standard way of feeding information to a machine.
Times change.
--
(setq mail '("tale@pawl.rpi.edu" "tale@itsgw.rpi.edu" "tale@rpitsmts.bitnet"))sean@ms.uky.edu (Sean Casey) (10/25/89)
steveb@cs.utexas.edu (Steve Benz) writes: |tchrist@convex.COM (Tom Christiansen) writes: || [ In response to the people-who-don't-read-mail-checker ] ||So as an exercise, I rewrote the program in perl (version |>3.0). |While I certainly find your program preferable to the original, |I question your choice of Perl instead of a shell script. |Granted, your Perl program would be faster on some systems, but |(at the risk of making a baseless assertion) the Bourne shell is |the standard language for writing administrative hackery. Yes and look at the godawful mess of AT&T "face", or any other vendor written shell scripts for that matter. It was done in perl because perl is a considerably more powerful programming language that runs on practically every Unix system and some micros to boot. Just because Bourne shell is everywhere doesn't mean it's the best tool. -- *** Sean Casey sean@ms.uky.edu, sean@ukma.bitnet, ukma!sean *** Copyright 1989 by Sean Casey. Only non-profit redistribution permitted. *** ``So if you weight long enough, you'll get your packets, right?''
tneff@bfmny0.UU.NET (Tom Neff) (10/25/89)
In article <13034@s.ms.uky.edu> sean@ms.uky.edu (Sean Casey) writes: >Yes and look at the godawful mess of AT&T "face", or any other vendor >written shell scripts for that matter. FACE is not a shell script, it is a monstrous overblown executable that interprets a blizzard of little twisty files, all different, to create a kludgy, elephantine windowing interface. Caveat lex luthor. -- "UNIX should be used :: Tom Neff <tneff@bfmny0.UU.NET> or as an adjective." -- AT&T :: ...uunet!bfmny0!tneff (UUCP only)
sean@ms.uky.edu (Sean Casey) (10/26/89)
tneff@bfmny0.UU.NET (Tom Neff) writes: |In article <13034@s.ms.uky.edu> sean@ms.uky.edu (Sean Casey) writes: |>Yes and look at the godawful mess of AT&T "face", or any other vendor |>written shell scripts for that matter. |FACE is not a shell script, it is a monstrous overblown executable that |interprets a blizzard of little twisty files, all different, to create |a kludgy, elephantine windowing interface. Caveat lex luthor. True. But face isn't just an executable. It calls up a whole mess of twisty shell scripts, all different. If, God Help You, you want to do things by hand or write your own programs, you get to hunt in these shell scripts because nowhere else is documented how they do certain things. Sean -- *** Sean Casey sean@ms.uky.edu, sean@ukma.bitnet, ukma!sean *** Copyright 1989 by Sean Casey. Only non-profit redistribution permitted. *** ``So if you weight long enough, you'll get your packets, right?''
steveb@cs.utexas.edu (Steve Benz) (10/26/89)
In article <13048@s.ms.uky.edu> sean@ms.uky.edu (Sean Casey) writes: > >... [ FACE ] calls up a whole mess of twisty >shell scripts, all different. If, God Help You, you want to do things by >hand or write your own programs, you get to hunt in these shell scripts >because nowhere else is documented how they do certain things. 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.) 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.) - Steve
jim@eda.com (Jim Budler) (10/26/89)
steveb@cs.utexas.edu (Steve Benz) writes: } In article <13048@s.ms.uky.edu> sean@ms.uky.edu (Sean Casey) writes: } 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.) } - Steve Heated words (not actually quoted above), for a simple pair of concepts. o sh + numerous basic unix utilities (sed, awk, ...) are generally available and familiar to administrators. Different versions of all portions exist. All bourne shell, awk, sed scripts are not fully portable because of this. o perl is new, flexible, and can be used for automating most administrative tasks. Available in source, for many machines, including non-UNIX. Not familiar to most administrators. They are not mutually exclusive points of view. Mild flame time: If a functional program is posted in <insert your favorite language>, it is counter productive to post a discussion of the relative merits of the choice of language. If you want to *demonstrate* an increased functionality of a <different language> then post source. Increased flame: I'm perfectly happy letting people worry about their own mail. I use 'watcher' (courtesy Kenneth Ingham, UNM Computing Center, Albuquerque, NM) to tell me when the file system gets too full. Nevertheless, the source code was useful 'cause it demonstrated useful capabilities. Don't discourage useful code. All flamed out. jim P.S. with all the moderators deciding what 'alternate' source is useful lately, I guess mod.sources wasn't so bad 8^( P.P.S here's some source, in perl. Now this is NOT very useful :^) Maybe not even correct 8^) -------------- cut here --------------- : This is a shar archive. Extract with sh, not csh. : The rest of this file will extract: : jul echo extracting - jul sed 's/^X//' > jul << '!EOR!' X#! /usr/bin/perl X X($a,$b,$c,$e,$f,$g,$h,$i,$j) = localtime(time); X++$i; Xprint "Julian date is $i\n"; !EOR! -- Jim Budler jim@eda.com ...!{decwrl,uunet}!eda!jim compuserve: 72415,1200 applelink: D4619 voice: +1 408 986-9585 fax: +1 408 748-1032
tchrist@convex.COM (Tom Christiansen) (10/26/89)
In article <936@rodan.cs.utexas.edu> steveb@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@convex.COM "EMACS belongs in <sys/errno.h>: Editor too big!"
nelson@sun.soe.clarkson.edu (Russ Nelson) (10/27/89)
Um, guys, we're not here to battle each other -- we're here to battle the lack of software. -- --russ (nelson@clutx [.bitnet | .clarkson.edu]) Live up to the light thou hast, and more will be granted thee. A recession now appears more than 2 years away -- John D. Mathon, 4 Oct 1989.
leres@ace.ee.lbl.gov (Craig Leres) (10/29/89)
Tom Christiansen writes: > Only if your vendor hasn't fixed biff(1) to save the st_atime from when > it stats the file and restore it with utimes(2) after you're done reading. The idea of hacking comsat to restore the access time is clever. Mind you, I don't like the race. But I suppose you could lock the mail drop while reading and updating the times. But that's probably not necessary because if you're already using biff to find out about new mail and you lose the race, the worst that happens is that csh won't notice that new mail has arrived. Craig P.S. In this case, my "vendor" is Berkeley.