Gary Funck asked,
| While debugging a procmail script (invoked with procmail -m, and
| with DEFAULT=| for stdout), I noticed that even though I set
| LOGFILE=unpack.log, that neither the output from VERBOSE=y or
| from assigning to LOG actually went to $LOGFILE (I dont' know
| where the output went), _unless_ I set MAILDIR to a _full_ pathname
| of the current directory.
|
| Is this the expected interaction between MAILDIR and LOGFILE?
When you use -m, procmail sets $MAILDIR by default to . (the current
directory when procmail was invoked); without -m, it defaults to $HOME
unless you name an rcfile on the command line that begins with "./",
in which case, again, it defaults to dot.
My guess is that procmail was running in a directory other than the one where
Gary expected it to, so he was looking in the wrong place for the logfile;
perhaps the procmail process was in a directory where it had no write per-
mission, in which case it couldn't create the logfile at all.
| I didn't particularly like the idea of hardwiring a full pathname
| into MAILDIR,
If you're using -m, you can't make assumptions about the starting value of
$MAILDIR, so you may have to do it despite disliking it. You should be able
to refer to $HOME, though, and assign MAILDIR=$HOME/test.
| ... and tried:
|
| MAILDIR=./
| MAILDIR=.
| MAILDIR=`pwd`
| MAILDIR=$PWD
|
| but none of the above changed the behavior of logging, I saw no output
| in the current directory.
|
| this worked:
| MAILDIR=/usr/people/gary/test
| Any idea what's going on here?
I think that /usr/people/gary/test wasn't the current directory when procmail
fired up. Did you call procmail -m from another procmail rcfile, in which
$MAILDIR had been defined, making the parent procmail chdir? Maybe
unpack.log is in *that* directory.