At 10:43 AM 7/11/97 +0900, Mitsuru Furukawa wrote:
Sean B. Straw,
lists> What is your favourite shell?
sh (Bourne shell)
Then that shell is what you should use for writing your shell scripts.
However, it has been said that sh is the stablest shell to use FROM
procmail (I don't recall why - possibly it is a portablility issue or that
sh is always available - but I stick to it for my procmail stuff anyway).
Since the scripts that are being discussed are NOT being exectuted from
procmail/your mailserver, (YOU are executing them at a shell prompt), this
doesn't matter.
lists> This problem doesn't sound like a procmail issue. The mail spool
is the
lists> "system mailbox" referred to above, and is exempt from the need for
special
lists> lockfiles.
So maybe I need to restate my question.
What I was _also_ doing was testing new piece of rc file by
formail -s procmail test.rc < test.mbox
test.mbox is not directly accessed by procmail and
mails should get into my mail spool at the end of test.rc.
test.rc is injecting messages into your mailspool?
Perhaps you could share your test.rc for others here to examine? Does this
standalone rc set procmail environment up as your .procmailrc file might
normally?
Is there any risk involved if any "legitimate" mail arrived
thus triggered procmail with "legitimate" .procmailrc
while I was testing?
Procmail would be spawned as a separate process, and should have processed
any mail as proper as the recipes it was given could handle them.
Another question is that if I added -m as
formail -s procmail -m test.rc < test.mbox
it ***Bounced***
and does not get into my mail spool even after my mail spool recovered.
Is this normal?
The only time I've seen the -m used is where procmail is used as a local
delivery agent from sendmail, in which case there are other arguments being
passed at the time. I don't know whether this is even supposed to work
with the arguments you've given it in a standalone mode. For what reason
did you decide you needed to use -m?
---
Please DO NOT carbon me on list replies. I'll get my copy from the list.
Sean B. Straw / Professional Software Engineering
Post Box 2395 / San Rafael, CA 94912-2395