"David W. Tamkin" <dattier(_at_)panix(_dot_)com> writes:
If you haven't yet assigned the LOGFILE variable, stderr will still point to
whatever destination was inherited from procmail's parent. So if you've
invoked procmail from an interactive shell,
* ? test -t 2
will pass; if procmail was invoked by the MTA either from the LDA definition
or from a pipe in ~/.forward or the alias file, or if procmail was invoked by
cron, stderr will not point to a terminal and that same condition will fail.
But note that once you assign LOGFILE to a file, or you make it null (just
LOGFILE= with no filename) or you unset LOGFILE, that distinction will be
lost, and it cannot be recovered. So you have to save the initial condition
in a variable near or at the top of .procmailrc:
INTERACTIVE=no
:0
* ? test -t 2
{ INTERACTIVE=yes }
And if /etc/procmailrc messes with the LOGFILE variable before you can do
that, well, you're out of luck.
Just out of curiousity, I looked into what would have to be done if
/etc/procmailrc were to mess with LOGFILE. I was inspired by the
mention of "procmail's parent" to come up with the following (which
appears to work, at least on my system)
FROMTTY=no
:0
* ? ps -ho tty `ps -ho ppid $$` | grep "[0-9]"
{ FROMTTY=yes }
Jeff
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail