Re: new zsh mailing list up and running

Re: new zsh mailing list up and running

[Mark Borges]

>> Richard Coleman(RC) wrote on Wed, 17 May 1995 22:04:00 -0400:
RC> I use (and highly recommend) procmail. If it helps anyone, I'll
RC> attach the procmail recipes I'm using to filter the new zsh
RC> mailing lists.
Thanks!

I know this is not a zsh question, but...

I've never used it (procmail) before -- I've been using elm's filter(1) --
but this looks much more flexible and powerful. I've skimmed through the
man pages, and I think I understand what you're doing below except for:


RC> ########################
RC> :0 w: zsh-announce/$LOCKEXT
RC> * ^Resent-from: *zsh-announce
RC> | rcvstore +zsh-announce              <<<<----
 
RC> :0 w: zsh-users/$LOCKEXT
RC> * ^Resent-from: *zsh-users
RC> | rcvstore +zsh-users
 
RC> :0 w: zsh-workers/$LOCKEXT
RC> * ^Resent-from: *zsh-workers
RC> | rcvstore +zsh-workers
RC> #########################

I gather you're filtering the mail through some external program (rcvstore)
we don't have. Why? If you have time, can you explain a bit more what the
above recipe accomplishes?

Also, in contrast to zsh-list, SmartList doesn't appear to provide a `Reply-To:'
header. Consequently, replies not go to the author and not to the
list. There was some lengthy discussion a while back about whether `Reply-To:'
should be set, and if so what it should be set to. The consensus was to
include it, and to set it to zsh-list. Do you not want to do this, or is
there another way?

  -mb-

Re: new zsh mailing list up and running

[Richard Coleman]

> I know this is not a zsh question, but...
>
> I've never used it (procmail) before -- I've been using elm's filter(1) --
> but this looks much more flexible and powerful. I've skimmed through the
> man pages, and I think I understand what you're doing below except for:

Although a lot of people use elm filter, it is not a very good mail filter
utility.  Procmail is definitely the best, probably followed by mailagent.
Mailagent is totally written in perl, so is a good choice for perl hackers.

Procmail is actually a fairly general purpose mail manipulation and filter
language.  As an example of its power, the mailing list manager I'm using
for zsh-{announce,users,workers} called SmartList is primarily written in
procmail (and some shell scripts and a couple of small utilities written in
C).

My procmail setup has an auto-responder built into it.  If you send me e-mail
with any of the following subjects (only one per mail message):

get procmailrc          # get a copy of my .procmailrc
get zsh faq             # get a copy of zsh FAQ
get pgp key             # get my pgp key

then my procmail mail gremlin will automatically send a response.

> RC> :0 w: zsh-announce/$LOCKEXT
> RC> * ^Resent-from: *zsh-announce
> RC> | rcvstore +zsh-announce              <<<<----
>  
> I gather you're filtering the mail through some external program (rcvstore)
> we don't have. Why? If you have time, can you explain a bit more what the
> above recipe accomplishes?

Rcvstore is a program that comes with the mh mail system.  This is only 
necessary
if you are using the mh mail system.  Mh and procmail work very well together.
I use the exmh front-end to mh.  The combination exmh+mh+procmail is one of the
best for dealing with high volumes of mail.

In mh, a folder is actually a directory and mail messages are keep in 
individual
files, rather than concatenating them together.  Sometimes this is a problem
for people who have quotas on the number of files that they can have (this is
to prevent i-node depletion) since this will limit the number of mail messages
you can keep around.  It also makes your e-mail setup incompatible with elm or
mailtool.  Personally I like this since it makes it easy to write scripts that
manipulate your mail  I have zsh shell functions that given the sequence number
of a mail message, will slurp in a mail message from my zsh-{list,workers} mail
folder and patch the zsh baseline source.

> Also, in contrast to zsh-list, SmartList doesn't appear to provide a `Reply-To:'
> header. Consequently, replies not go to the author and not to the
> list. There was some lengthy discussion a while back about whether `Reply-To:'
> should be set, and if so what it should be set to. The consensus was to
> include it, and to set it to zsh-list. Do you not want to do this, or is
> there another way?

I can never decide which way I think is best.  The problem with setting the
Reply-To field back to the list is that this strips out information that
sometimes is necessary if you do want to respond directly to the sender
rather than the list.  Also there is the risk that people will accidently send
things to the list that they didn't intend for everyone to see.

I think the best thing to do is continue with the current configuration for
now and see how it works.  If it turns out to be inconvenient, then I
can easily change it.

rc
zsh@math.gatech.edu

Re: procmail recipes

[Geoff Wing]

:> RC> :0 w: zsh-announce/$LOCKEXT
:> RC> * ^Resent-from: *zsh-announce
:> RC> | rcvstore +zsh-announce              <<<<----
:> I gather you're filtering the mail through some external program (rcvstore)
:> we don't have. Why? If you have time, can you explain a bit more what the
:> above recipe accomplishes?
:Rcvstore is a program that comes with the mh mail system.  This is only 
:necessary if you are using the mh mail system.  Mh and procmail work very
[...deleted...]
:In mh, a folder is actually a directory and mail messages are keep in 
:individual
:files, rather than concatenating them together.  Sometimes this is a problem
[...deleted...]

If you want store in individual files, but not use the rcvstore program, you
might try the following procmailrc recipes, which store the lists in
3 different directories. Each message is stored as its message number.

:0: 				# Zsh announce mailing list
* ^Resent-Sender: zsh
* ^X-Mailing-List: <zsh-announce.*\/[0-9]+
zsh-announce/$MATCH

:0: 				# Zsh users mailing list
* ^Resent-Sender: zsh
* ^X-Mailing-List: <zsh-users.*\/[0-9]+
zsh-users/$MATCH

:0: 				# Zsh workers mailing list
* ^Resent-Sender: zsh
* ^X-Mailing-List: <zsh-workers.*\/[0-9]+
zsh-workers/$MATCH

-- 
Mason [G.C.W]  mason@werple.mira.net.au     Hurt...Agony...Pain...LOVE-IT

Re: new zsh mailing list up and running

[Samuel Tardieu]

>>>>> "Richard" == Richard Coleman <coleman@math.gatech.edu> writes:

Richard> The combination exmh+mh+procmail is one of
Richard> the best for dealing with high volumes of mail.

Mmmm... I'm not quite sure you're right. Have you ever tested
(ding) Gnus for Emacs ? This is still in alpha stage, but it is really
stable now (http://www.ifi.uio.no/~larsi/ for more information).

I use procmail + (ding) Gnus to handle every day about 600 mails (a
lot of mailing-lists, postmaster for a 2000+ students organization,
...) and it works fine ; (ding) Gnus consider mails as being news in a
private spool. This implies that your mail gets threaded as usenet
news are, and that newsgroups and mailgroups are mixed. You also have
a level associated to each group (mail or news) which correspond to a
priority of the articles in it.

You can choose between a lot of back-ends to store your mails with
(ding) Gnus: nnml is a custom one, nnmh stores them in the mh way,
nnmbox keeps everything in one Unix mailbox, you can read mail stores
using Rmail format, ...

The kill process (which now applies to mail as well as to news) has
been enhanced: it's now a score process. You may (temporarily or
definitively) raise or lower someone's score, a subject, a
cross-posting, ..., and sort your group buffer by score.

Ok, I'll stop this advertisement now :-) Anyway, I'm very happy with my
zsh+procmail+(ding)Gnus+X11R6 setup :)

Richard> I can never decide which way I think is best.  The problem
Richard> with setting the Reply-To field back to the list is that this
Richard> strips out information that sometimes is necessary if you do
Richard> want to respond directly to the sender rather than the list.
Richard> Also there is the risk that people will accidently send
Richard> things to the list that they didn't intend for everyone to
Richard> see.

I strongly agree with this. Some lists I've subscribed to do set this
"Reply-To" header ; there is a lot of garbage on each of these lists,
such as "Oh, John, I didn't know you were still alive, how are you,
your wife, your children" and such because people think they're
answering to John only.

  Sam
--
"La cervelle des petits enfants, ca doit avoir comme un petit gout de noisette"
                                                       Charles Baudelaire

Re: new zsh mailing list up and running

[Martin Hamilton]

Richard Coleman writes:

| I use the exmh front-end to mh.  The combination exmh+mh+procmail is one
| of the best for dealing with high volumes of mail.

For anyone who's interested, there's some blurb about exmh on the web ...

Europe: <URL:http://www.rosat.mpe-garching.mpg.de/~ach/exmh/>
USA:    <URL:ftp://parcftp.xerox.com/pub/exmh/html/index.html>

Martin

Re: Deliver script (was Re: procmail)

[Chip Salzenberg]

According to Geoff Wing:
> If you want store in individual files, but not use the rcvstore program, you
> might try the following procmailrc recipes, which store the lists in
> 3 different directories. Each message is stored as its message number.
> 
> :0: 				# Zsh announce mailing list
> * ^Resent-Sender: zsh
> * ^X-Mailing-List: <zsh-announce.*\/[0-9]+
> zsh-announce/$MATCH
> 
> :0: 				# Zsh users mailing list
> * ^Resent-Sender: zsh
> * ^X-Mailing-List: <zsh-users.*\/[0-9]+
> zsh-users/$MATCH
> 
> :0: 				# Zsh workers mailing list
> * ^Resent-Sender: zsh
> * ^X-Mailing-List: <zsh-workers.*\/[0-9]+
> zsh-workers/$MATCH

You should be able to do the same thing with Deliver.  Assuming you
have Perl (DON'T YOU?), your .deliver file would look like:

----------------------------------------------------------------
#!/usr/bin/perl

open(H, $ENV{'HEADER'});
while (<H>) {
	if (/^X-Mailing-List: <(zsh-\w+)[^/]*/(\d+)/) {
		print $1, "/", $2, "\n";
		exit;
	}
}
close(H);

print $ARGV[0], "\n";
----------------------------------------------------------------



-- 
            Chip Salzenberg, aka <chip@cybernetics.net>
     "And remember to worship at the railroad of your choice."
        -- Mike Nelson, MST3K: "The Amazing Transparent Man"

problems with $WATCH / $WATCHFMT

[Matt Chidambaram]

i have recently (till this morning) been using zsh version 2.6 beta10, 
on the following setups:

 linux (486)
 hppa (hpux 9.05) 9000/715
 dec alpha osf/1 v3.x

now, (as of this afternoon) i have been using zsh version 2.6 beta12, on 
the same platforms.

all of the following apply to both beta10 and beta12 flavours....

i have recently discovered the following features:

export WATCH=all
export WATCHFMT="%n has %a %l from %m @ %T."
export LOGCHECK=1

however there seems to be a discrepency between the information (time)
displayed in identical xterms that display login/out info on the same 
machine, about users.

essentially, i have many xterms on my screen at once - but i only really 
work in two or three of them through the day.

in those xterms that i work in - sometimes when i press return (every few 
minutes), the screen displays various peoples id's tty's and login times.

in those xterms that i dont work in very often - nothing happens until i 
press return every so often (ie every couple of hours); in these xterms - 
when i get the very similar login/out information as the other xterms - 
its great - except for the fact that the login/out times are effectively 
(plus/minus a minute) the time of day when i pressed return in that 
xterm/shell on that machine.

is this a [bug|feature|error-on-my-part] ?

ok - here's a wish for zsh ....

is there any way of getting these login/out pieces of information to 
auto-interrupt my shell - without me having to press return before it 
displays the information? - say by setting an environemnt variable.

[ie similar action to biff command -> if biff is active, it will auto 
interrupt my application etc and inform me of new mail, and the first 
few lines of the mail/ if biff is inactive then it wont]

ok thats the first problem over with ...

the second problem is the one about installing zsh on dec alpha running 
osf/1 v3.x ....

after reading the FAQ and doing as it says about copying ypclnt.h and 
altering the yp_all() signature's third parameter; i still get errors 
concerning the zle_tricky.c call to yp_all();

i eventually altered the call from within zle_tricky.c ....
from:
    yp_all(domain, PASSWD_MAP, &cb);
to:
    yp_all(domain, PASSWD_MAP, cb);

it compiles and runs ok now. i havent tested it fully.
( - but it hasnt crashed as yet...)

is the change i made valid/correct?

ok.

any help on these matters would be most appreciated.

keep up the good work.

matt.

Thought for the Day: We are the people our parents warned us about.
__________________________________________________________________________
Prism Technologies Ltd.,    |                 Matt
KingFisher House, Kingsway, |  Tel No.    +44 (0)191 491 3983
Team Valley, Gateshead,     |  Fax No.    +44 (0)191 491 3973          
Tyne & Wear, England,       |  EMail.     mc@prismtech.co.uk
NE11  0JQ, U.K.             |  WWW Page   http://www.prismtech.co.uk/
__________________________________________________________________________

Re: problems with $WATCH / $WATCHFMT

[Zoltan Hidvegi]

> the second problem is the one about installing zsh on dec alpha running 
> osf/1 v3.x ....
> 
> after reading the FAQ and doing as it says about copying ypclnt.h and 
> altering the yp_all() signature's third parameter; i still get errors 
> concerning the zle_tricky.c call to yp_all();
> 
> i eventually altered the call from within zle_tricky.c ....
> from:
>     yp_all(domain, PASSWD_MAP, &cb);
> to:
>     yp_all(domain, PASSWD_MAP, cb);
> 
> it compiles and runs ok now. i havent tested it fully.
> ( - but it hasnt crashed as yet...)
> 
> is the change i made valid/correct?

No it isn't.  The FAQ says that you should not change zle_tricky.c.  If it
compiles after your change it means that you did not change the header file.
The correct prototype for yp_all is

extern int yp_all(char *, char *, struct ypall_callback *);

That's what the faq says.  zle_tricky.c is correct.  Fix
/usr/inclide/rpcsvc/ypclnt.h.  If you do not have root privileges ask your
sysadmin to do it.  Or you may create an rpcsvc subdirectory in the zsh
directory and place the fixed ypclnt.h there (I did not try it but it should
work).

I think that should be mentioned in the FAQ.

Cheers,

Zoltan

Re: problems with $WATCH / $WATCHFMT

[Peter Stephenson]

mc@prismtech.co.uk wrote:
> in those xterms that i dont work in very often - nothing happens until i 
> press return every so often (ie every couple of hours); in these xterms - 
> when i get the very similar login/out information as the other xterms - 
> its great - except for the fact that the login/out times are effectively 
> (plus/minus a minute) the time of day when i pressed return in that 
> xterm/shell on that machine.

A problem is that after someone's logged out, they're not in utmp any
more, so the real logout time is impossible to get.  The login time
should be OK, however ---- assuming the user is still logged on ---
otherwise it's a bug.

> is there any way of getting these login/out pieces of information to 
> auto-interrupt my shell - without me having to press return before it 
> displays the information? - say by setting an environemnt variable.

That's hard:  you'd actually have to get the shell itself to wake up
and check every now and then.  You might be best doing it some other
way, like a script running in the background.

> after reading the FAQ and doing as it says about copying ypclnt.h and 
> altering the yp_all() signature's third parameter; i still get errors 
> concerning the zle_tricky.c call to yp_all();
> 
> i eventually altered the call from within zle_tricky.c ....
> from:
>     yp_all(domain, PASSWD_MAP, &cb);
> to:
>     yp_all(domain, PASSWD_MAP, cb);

That won't do:  it definitely has to be &cb.  The problems will start
when you try completing user names.  It sounds like your problem is
with including the right version of ypclnt.h.  Maybe I didn't put all
the instructions in the FAQ.  At worst, change the #include for
ypclnt.h to 
#include "my_ypclnt.h"
where my_ypclnt.h is the local modified copy of the header with the
corrected prototype.

-- 
Peter Stephenson <pws@ifh.de>       Tel: +49 33762 77366
WWW:  http://www.ifh.de/~pws/       Fax: +49 33762 77330
Deutches Electronen-Synchrotron --- Institut fuer Hochenergiephysik Zeuthen
DESY-IfH, 15735 Zeuthen, Germany.