maart@cs.vu.nl (Maarten Litmaath) (05/09/89)
dhesi@bsu-cs.bsu.edu (Rahul Dhesi) writes: \You might want to set csh's "mail" variable like this: \ set mail=(30 /usr/spool/mail/$USER) \which will cause csh to check for mail every 30 seconds. ... but only if it's about to print the prompt! :-( This scheme is called `synchronous' mail checking. There are 2 `better' ways to check for mail: 1) `asynchronous' checking - at login time start up a daemon, which periodically monitors the mailbox, to print a message to the terminal as soon as it discovers a mailbox size > 0. Disadvantage: one has to start an extra process, which either sits idle most of the time, or is constantly busy checking an empty mailbox. 2) a mail alerter, ala MMDF's rcvalert(1) - instead of putting incoming messages straight into the mailbox, they're piped into a notification program, which decides what to do with the message, e.g. deleting it, forwarding it, notifying the recipient or simply putting it into the mailbox. This scheme is obviously the best: simply let the mail delivery program start up the filter mentioned in ~/.maildelivery (MMDF) or ~/.mailrc (MAIL), which will terminate as soon as the message has been `delivered'. However, nowadays the problem is mail getting handled by another machine (typically a file server) than the one onto which you're logged in. A solution is to let the filter find out where you really are (IF you're logged in somewhere at all). A general problem with mail notification programs is: how to alert the user? rcvalert's method is to print a message (with a beep) to the terminal ONCE. But what if the user was having a coffee break and some other program's output caused the message to scroll off the screen? That's not what I call `mail notification'. On the other hand you don't want a continuous stream of beeps either, lest the other people in the room will perform free fall experiments with your terminal. The solution is to re-alert the user after, say, 3 minutes have passed without the mailbox (modification/access time) having changed. Below is an MMDF-style mail notification executable shell script. To enable it put something like the following into ~/.maildelivery (see maildelivery(5)): * - | R /usr/solo/maart/etc/rcvalarm The relevant portion of the script is carried out in the background by a subshell, in order to let the wait(2) by the invoker return `immediately'. To stop `rcvalarm' from nagging about unread mail, the user can create a file `~/.ok'; this action is preferably put into an alias or a shell script. Once spotted, the file will be removed, to re-enable notification of (future) mail. If somebody's interested: I've got a `daemon' version as well. Questions & remarks to: Maarten Litmaath @ VU Amsterdam: maart@cs.vu.nl, mcvax!botter!maart ----------8<----------8<----------8<----------8<----------8<---------- #! /bin/sh # @(#)rcvalarm 3.2 89/01/10 Maarten Litmaath # # rcvalarm is started up at maildelivery (see maildelivery(5)) # it checks if the user is logged in on any of the machines specified in # $HOME/.rcvalarm, or all machines if this file is empty or does not exist # it keeps alerting the user until: # - the access/modify time of the mailbox has been changed # - the file $HOME/.ok has been created, which will be removed ( cd user=`whoami` alarm=`echo aaaaaaaaaa | tr a '\07'` message=$alarm"You have mail @ `hostname`." tmp=/tmp/rcvalarm.$$ ok=.ok umask 077 set - `ls -l mailbox` mod="$5$6$7" set - `ls -lu mailbox` acc="$5$6$7" [ -f .rcvalarm ] && machines=`cat .rcvalarm` while : do /bin/rm -f $tmp exec 3> $tmp 4< $tmp /bin/rm $tmp exec 5> $tmp 6< $tmp /bin/rm $tmp success=0 rusers $machines | grep "\<$user\>" >&3 # why does piping into the `while read' loops fail? while read session <&4 do machine=`echo "$session" | sed 's/[ .].*//'` /usr/ucb/rsh $machine -n who | grep "^$user\>" >&5 while read slot <&6 do set - `ls -lu mailbox` a="$5$6$7" set - `ls -l mailbox` m="$5$6$7" [ "$a" != "$acc" -o "$m" != "$mod" -o -f $ok ] && { /bin/rm -f $ok exit 0 } set - $slot error=`/usr/ucb/rsh $machine -n \ sh -c "'echo $message 2>&1 > /dev/$2'" 2>&1` [ x"$error" = x ] && success=1 done done [ $success = 1 ] || exit 0 sleep 180 done ) & ----------8<----------8<----------8<----------8<----------8<---------- -- "If it isn't aesthetically pleasing, |Maarten Litmaath @ VU Amsterdam: it's probably wrong." (jim@bilpin) |maart@cs.vu.nl, mcvax!botter!maart
maart@cs.vu.nl (Maarten Litmaath) (05/09/89)
maart@cs.vu.nl (Maarten Litmaath) writes:
\... This scheme is obviously the best: simply let the mail delivery
\ program start up the filter mentioned in ~/.maildelivery (MMDF) or
\ ~/.mailrc (MAIL), [...]
^^^^^^^^^
Make that ~/.forward.
--
"If it isn't aesthetically pleasing, |Maarten Litmaath @ VU Amsterdam:
it's probably wrong." (jim@bilpin) |maart@cs.vu.nl, mcvax!botter!maartepmcmanus@csvax1.cs.tcd.ie (05/12/89)
In article <2462@solo9.cs.vu.nl>, maart@cs.vu.nl (Maarten Litmaath) writes: > A general problem with mail notification programs is: how to alert the user? > rcvalert's method is to print a message (with a beep) to the terminal ONCE. > But what if the user was having a coffee break and some other program's output > caused the message to scroll off the screen? Actually I think that it is adequate to notify just once, provided shell notification is also enabled. That way there is immediate notification when you are actually there, and a guarantee of later notification if you miss that. I mention this because I have a C program that performs much the same function of remote notification as Maarten's script. But it just grabs the output of rwho, and if the user is not mentioned does nothing else. This is important in an environment where circulars sent to many users are common. You want as few commands as possible to be executed for such a message; otherwise the system will be swamped with .maildelivery processes. If anyone is interested in this program I would be happy to mail it to them. -- Eamonn McManus emcmanus@cs.tcd.ie uunet!mcvax!cs.tcd.ie!emcmanus