Mark Borges continued,
| Since I didn't see any trace of what the value procmail thinks these
| hold in the logfile, is there any other way to force procmail to say
| what they actually are?
Youch; I didn't notice it the first time, but you didn't define LOGFILE
until after you assigned DEFAULT, so when DEFAULT was given its value, there
was nowhere to record the action. If the logfile exists and verbosity is on,
procmail will log assignments of variables.
You can also do this (after defining $LOGFILE):
LOG="The current setting of DEFAULT is $DEFAULT.
"
Anything assigned to the variable LOG will be appended immediately to the
logfile, if one is defined. Note that a trailing newline (so that the next
log entry doesn't start immediately to the right of the period) must be
included explicitly; that's why the closing quote is on the next line.
| VERBOSE = on
| MAILDIR = $HOME/Mail/spool # You'd better make sure it exists
| ORGMAIL = /var/mail/$LOGNAME
| DEFAULT = $MAILDIR/mbox.spool
| LOGFILE = $MAILDIR/log.procmail
So just move LOGFILE= above DEFAULT= if you still want to see it. But as you
wrote later,
| Since it works fine when I explicitly tell procmail what to do by
| adding the two lines,
| :0 :
| $DEFAULT
| at the very end, doesn't this indicate that DEFAULT is in fact being
| set correctly, and that it is not having a problem saving it there?
Yes, it does. Good catch. I just find it so strange that (without the
explicit recipe) procmail isn't even trying to save to $DEFAULT before
saving to $ORGMAIL, but that's why you're writing in the first place.
| Could this be a platform-dependent bug? I'm on a,
| $ uname -a
| SunOS solberg 5.5 Generic_103093-03 sun4m sparc SUNW,SPARCstation-20
What version of procmail are you running? (What does `procmail -v` say?)
Maybe you're running an old version that had that bug, though I can see
that your version is new enough for asterisk notation.