Bill Moseley <moseley(_at_)netcom(_dot_)com> writes:
I've got a recipe that I use to rename a file using mv. Sometimes I get an
error in my log file and I don't understand why. I guess I could use the
"i" flag, but I'd like to know why I would need to.
...
Even though there is an error reported, the file is renamed okay. But I'm
curious why I get the error. Is it because I'm piping the message to a
program the doesn't take std input? Why do I only get the error sometimes?
The error occurs when procmail gets a SIGPIPE, indicating that the only
reader left on the pipe has closed it. In this case, mv closed the pipe
when it exited, without having read anything. For most mail processing
programs, exiting early like that would indicate something wrong. For
something like mv, this expected.
Now for the tricky one. It's possible for procmail to be scheduled
before the mv. If it is, and the message is small enough, procmail
could write the entire message into the pipe buffer in the kernel
before the mv exited. Since procmail has already closed the pipe,
the kernel has no reason to send the SIGPIPE, and thus the error won't
occur.
So should I use the "i" flag and just ignore the error, or would another
syntax be better. Such as:
DUMMY=`/usr/bin/mv $FILE $FILE.save`
Procmail will still provide the mail message on stdin to the mv, so this
is no more efficient. I think the current feeling is that something like:
:0 wcih
| /usr/bin/mv $FILE $FILE.save
is best. Note that this uses the 'h' flag to send only the header,
as it's usually smaller than the body.
Philip Guenther