Dallman Ross wrote,
One does need to keep in mind, though, that in procmail there is
no real difference between unset and set-to-null; at least in
how we read or expand the parameters inside procmail.
That's by our choice, Dallman. There *normally* is no real difference
to procmail users between null variables and unset ones. In most cases
we care only about whether a variable is non-null or not non-null, so we
use conditions like these:
* var ?? .
or
* var ?? ^^^^
which treat the null and the unset alike. But that's a user choice.
When a situation arises where it makes a difference, procmail can handle
it. We just saw that within Panix discussing subaddresses, remember,
and I shared code that left the subaddress variable unset for mail to
user(_at_)panix(_dot_)com yet set but null for mail to user+(_at_)panix(_dot_)com(_dot_)
I'll never forget what happened on this list when someone asked, "How do
I test whether a variable is set but null?" A flood of replies came,
none of them distinguishing null from unset and therefore none of them
helpful (and many of them requiring shells or forks). Typical of them:
* ? if test -z x"$VAR" ; \
then : ; \
else false ; \
fi
(as if
* ? test -z x"$VAR"
wouldn't have been bad enough).
When I checked email and saw the load of wrong answers, I just shook and
shook my head. Then I sighed and posted,
* $ !${VAR+!}${VAR:+!}
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail