xbiff-like program to monitor remote mailbox?
David Wolfskill
david at catwhisker.org
Wed Dec 5 11:11:53 PST 2007
On Mon, Nov 19, 2007 at 01:43:11PM -0800, David Wolfskill wrote:
> This may well be a self-inflicted wound, but I'd kinda like to find a
> reasonably elegant way around it regardless....
>...
> I think what I want is something that can run on a system that supports
> X, but that has a somewhat more general way to determine the salient
> attributes of a mailbox (which may well reside on a remote machine).
>
> Any suggestions?
I received a few suggestions, and I looked into some of them.
Yes, I am (as one responder alluded) an "xterms & window manager" type
of person. In particular, the window manager I use most often is piewm,
which is a slight modification of tvtwm, which is essentially twm but
with the possibility of multiple "desktops". I gather that some folks
-- for whatever reasons -- use environments that are fancier; I don't.
I did manage to get one of the pointed-to programs to "work," after a
fashion, but for my purposes, it seemed awkward, at best: I opt to run
my MUA (mutt) from my desktop machine, and set it up to talk IMAP over
an SSH tunnel to the IMAP server. Thus, while having the notification
service also use IMAP is a possibility, it's slightly clunky.
But: I did find (for some plausible use of the term "find") an approach
that appears to be working for me:
I looked at the man page for xbiff(1) and noted the stanza labeled
"checkCommand," which reads:
|X DEFAULTS
| The application class name is XBiff. This program uses the Mailbox
| widget. It understands all of the core resource names and classes as
| well as:
|
| checkCommand (class CheckCommand)
| Specifies a shell command to be executed to check for new mail
| rather than examining the size of file. The specified string
| value is used as the argument to a system(3) call and may
| therefore contain i/o redirection. An exit status of 0 indi-
| cates that new mail is waiting, 1 indicates that there has been
| no change in size, and 2 indicates that the mail has been
| cleared. By default, no shell command is provided.
and tried my hand at cobbling up a Perl script that could be invoked as
the xbiff checkCommand, with some reasonable success.
I'm lousy at naming things, so the script is currently called "rbiff."
It uses "ssh -x" to issue "ls -lT" and "ls -lTu" against the mailbox on
the remote system (assuming UNIX mbox format, vs. (e.g.) MailDir). And
it doesn't really need much privilege to do that much -- just enough to
login & do an "ls -l" against a file.
Anyway, it uses those commands to obtain the size, atime, and mtime of
the file, stuffs those away in a file (~/.rbiff_status), along with
information about the name of the remote host, the username, and the
file to check, and then, on re-invocation, uses the stored information
at the "previous values"for comparison.
So this way, I can still use xbiff(1), but there is no requirement that
X stuff reside on the remote system at all. :-}
I invoked it as
xbiff -xrm 'xbiff*checkCommand: rbiff -s harry'
(where "harry" is the name of the remote server; the remote username was
the same as that on the invoking system, so I let it default. And the
mailbox filename to check worked with the default as well, so I left it
alone, too).
So thanks, folks, for your suggestions anyway.
If anyone's interested in my little script, I can make it available.
Peace,
david
--
David H. Wolfskill david at catwhisker.org
Proprietary data formats obfuscate, rather than disseminate, information.
See http://www.catwhisker.org/~david/publickey.gpg for my public key.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <http://www.baylisa.org/pipermail/baylisa/attachments/20071205/4e17255a/attachment.bin>
More information about the Baylisa
mailing list