Martin Mokrejs <mmokrejs(_at_)natur(_dot_)cuni(_dot_)cz> writes:
is it correct that procmail requires fullpath to rcfile (if not one in
/etc/procmail)?
No.
Is it true that rcfile must preceed -m option? (see below in examples).
Yes.
Why is procmail "fixing" always the mbox format and leaves only first
From_. All other occurencies are fixed by prepending >. This is meantion
Because if it doesn't, the message would be split. It only does this
if it's writing the message to a Berkeley mbox-style mailbox.
in manpage, it also says that is not done if the user is root. Hou can a
poor user disable this feature? Similar feature exists in formail, but it
seems I'm allowed to disable it at least. ;-) Anyway, it's not nice that
it requests UID=0.
I'm not sure where you're seeing this in the manpage. Could you please
quote the relevant text from the manpage?
...
The reason I want to use -m option is that I just want to use procmail to
extract dates and write them down, I don't want it to send the whole
mailbox file to my /var/spool/username.
As someone else has pointed out, you need to use "formail -s" to split
the mailbox in to multiple messages.
As for when rcfiles having to be full, let's first consider what the
manpage says:
Any other arguments are presumed to be rcfile paths
(either absolute, or if they start with `./' relative to
the current directory; any other relative path is relative
to $HOME, unless the -m option has been given, in which
case all relative paths are relative to the current direc-
tory); procmail will start with the first one it finds on
the command line. The following ones will only be parsed
if the preceding ones have a not matching HOST-directive
entry, or in case they should not exist.
So, for the normal case of a single rcfile, procmail does one of the
following:
1) If the rcfile path starts with "/", then it's an absolute path and
procmail uses it just like that.
2) If it starts with "./", then it's considered as relative to the
current directory.
3) If procmail is in mailfilter mode (the -m option was given), then
the rcfile path is relative to the current directory.
4) Otherwise, the rcfile path is relative to your home directory.
host# procmail VERBOSE=on date.rc < new.mbox
procmail: [27802] Thu Sep 30 23:06:27 1999
procmail: Couldn't read "//date.rc"
...
This matched case (4) above, and so was treated as $HOME/date.rc
host# procmail VERBOSE=on -m `pwd`\/date.rc < new.mbox
procmail: [27793] Thu Sep 30 23:03:53 1999
procmail: Couldn't read "//-m"
procmail: Rcfile: "/scratch/krb4/krb4.archive/date.rc"
...
host# procmail VERBOSE=on `pwd`\/date.rc -m < new.mbox
procmail: [27798] Thu Sep 30 23:04:24 1999
procmail: Rcfile: "/scratch/krb4/krb4.archive/date.rc"
...
Variable assignments and rcfiles go _after_ the -m option, not before.
Once procmail sees something that doesn't look like an option, it stops
looking for options. Just look at the output of "procmail -h":
lunen% procmail -h
Usage: procmail [-vptoY] [-f fromwhom] [parameter=value | rcfile] ...
Or: procmail [-toY] [-f fromwhom] [-a argument] -d recipient ...
Or: procmail [-ptY] [-f fromwhom] -m [parameter=value] ... rcfile [arg] ...
...
What you probably want to be doing is either:
procmail VERBOSE=on ./date.rc <message
or
procmail -m VERBOSE=on date.rc <message
I suspect the former is the right one, but you didn't describe what you
were doing enough to say.
Philip Guenther