Subject: Re: more than one command

From: Jeremy Mathers <[email-masked]>
Date: Wed, 25 Jan 1995 11:07:40 -0600

Somebody wrote:
>I read the manual pages an I am quite confused ath the moment. Isn't it
>possible to write a "newbie" version?

I think Nancy's Procmail "FAQ" is what you are looking for.

I definitely agree with you that the man pages are woefully inadequate.
The implementors seem to have a "If you can't get it from the man pages,
then you are not worthy" attitude - which is not at all uncommon in the
Unix world.  The basic problem is that man pages were never intended to
be tutorials (which, in later years, they seem to have evolved into).
This phenom is also noted in other areas - for example, Expect and Dmake
have man pages that are way too long - in fact, the Dmake man page lists
in its Bugs section the following: "This man page is way too long."
(I really like that!)

I've been pushing for a long time that a regular tutorial is needed; the
FAQ seems to be it, although it isn't really a FAQ in the traditional sense.

>I have occured following problem. I simply want to have a mail stored in a
>folder *AND* execute a program in which it should be piped into. Following
>entry does only execute the first line (storing the mail in the labnews
>folder":

>:0:
>* ^Subject: .*Lab:*
>labnews
>| /share/bin/hypermail -l "Lab News" -i -u -d "/wwwserver/labnews"

>What is missing?

Procmail by definition executes exactly one action line per recipe.
This can probably be seen to be a feature...

Try:

:0:
* ^Subject: .*Lab:*
labnews
:0A:
| /share/bin/hypermail -l "Lab News" -i -u -d "/wwwserver/labnews"

I think it will also work if you put the 'c' flag on the first rule,
then you don't need the 'A' flag on the second one.

---

From: [email-masked] (David W. Tamkin)
Date: Wed, 25 Jan 1995 13:13:24 -0600 (CST)

Jeremy Mathers answered Oliver Wrede,

| Try:
| 
| :0:
| * ^Subject: .*Lab:*
| labnews
| :0A:
| | /share/bin/hypermail -l "Lab News" -i -u -d "/wwwserver/labnews"
| 
| I think it will also work if you put the 'c' flag on the first rule,
| then you don't need the 'A' flag on the second one.

You need both the `c' and the `A', plus Robert Kerns's two suggestions:
first that the condition should read

* ^Subject: .*Lab:

without the trailing asterisk, and second, that the second recipe needs a
name for its local lockfile if it needs a local lockfile at all.

---

From: "Michael J. Corrigan" <[email-masked]>
Date: Wed, 25 Jan 1995 11:29:49 -0800

> then you don't need the 'A' flag on the second one.

It think it will *only* work if you put the 'c' flag on the first rule.
If a rule causes delivery (file into labnews in this case) then procmail
is finished.

The dependence on the previous recipe that the 'A' flag description
is referring is relevant only if procmail even gets to the recipe
with the 'A' flag.

---

From: "J. Daniel Smith" <[email-masked]>
Date: Wed, 25 Jan 95 15:49:11 -0500

Richard Coleman ([email-masked]) writes on 25 January 1995 at 14:17:01 -0500
>-----BEGIN PGP SIGNED MESSAGE-----
>
>content-type: text/plain; charset="us-ascii"
>
>> [...]
>I think man pages should be short and to the point.  I don't want to
>have to look through a tutorial to find a quick reminder about a
>certain flag.  I think the man pages for procmail are very nicely done.

Agreed.  I don't want to dig through mountains of prose just to
refresh my memory about something.

Unix "man" pages tend to have the flavor of being for people who know
what they are looking for and want a quick answer to a question.  If
you don't know what the question is, looking in the man pages may not
be helpful (although in this case "procmailex" has many nice
examples).

I can't comment much on the need for a procmail tutorial, but let's
keep this seperate from the man pages.

   Dan
----------------------- message is author's opinion only ----------------------
J. Daniel Smith <[email-masked]>                   http://www.bristol.com/~dan
Bristol Technology Inc.	                        +1 203 438 6969, 438-5013 (FAX)
Ridgefield, Connecticut (USA)                           {info,[email-masked]
                                --------
 Von guten Maechten wunderbar geboren, erwarten wir getrost, was kommen mag.
 Gott ist mit uns am Abend und am Morgen, und ganz gewiss an jedem neuen Tag.
	- Dietrich Bonhoeffer

---

From: Steve Morris <[email-masked]>
Date: Fri, 3 Feb 1995 18:57:10 -0500

Jeremy Mathers writes:
 > Unix world.

Actually you are being a little unfair here. Stephen has always been
most helpful and courteous. The harsh attitude comes from the groupies
who seem to think that any critcism is equivalent to heresy against
the religion of free software. Fortunately I have always found that
these groupies help anyway. The popular format for a help request that
contains a complaint about the manual is: a detailed helpful response,
followed by a quote from the manual that covers the issue, followed by
a snide implication that the fault is in your lazyness or stupidity in
not finding and understanding the particular manual section.

This is annoying but you have to admit that it is a lot more helpful
than a sharp stick in the eye. It is possible that the desire to prove
that the manual was adequate after all leads to more detailed help.
Certainly having the detailed help juxtaposed with the relevent manual
contents has more than once helped me to finally understand what the
manual was trying to say.

The best solution when requesting help is to not mention your opinion
of the manual. Abject apology at your own admitted failings helps
also. Comments like "I'm sure that I'm missing something obvious here
but ..." should be liberally sprinkled through the help request.
Remember that people on this list help for free. All they get is a
little ego gratification. Don't begrudge them this meager compensation
for their time. Also remember that you are asking for a favor and word
the request accordingly.

And don't pick on "The Implementer." He's a nice guy. Really!

If you really think the manual needs work, offer to help. That's what
Nancy did. Maybe after you figure something out you can send in a
proposed change to the manual that would have made things clearer. One
more complainer won't change things regardless of the validity of the
complaint.

Regards,

Steve Morris