dattier(_at_)wwa(_dot_)com (David W. Tamkin) writes:
process(_at_)qz(_dot_)little-neck(_dot_)ny(_dot_)us wrote:
| I think newer procmails know /dev/null and don't even bother opening it.
Newer procmails know to ignore a local lockfile on a drop to /dev/null --
that is, they know not to create /dev/null.$LOCKEXT. I don't know whether
they recognize anything else special about /dev/null.
Procmail knows that it shouldn't create a locallock on /dev/null and
that it shouldn't kernel lock /dev/null, and it knows to write it "raw"
(no "From " escaping or appended newline). This means that procmail
simply opens /dev/null, does it's write with one system call, and
closes it.
I'm not sure if adding the 'h' flag makes a real differance on modern
UNIX kernels. I suppose it depends on how optimized the write() data
is and in particular, whether a user-space to kernel-space copy is
_required_, or whether it's delayed. If it's delayed then the code for
handling /dev/null would presumably not do it, and the size of the
write wouldn't actually matter.
Philip Guenther