On Fri, 28 Mar 1997 17:07:52 +0100 (GMT+0100),
Jesper Pedersen <blackie(_at_)imada(_dot_)ou(_dot_)dk> wrote:
| >|echo $VAR8 lines, `/usr/local/gnu/bin/date +%e`/`/usr/local/gnu/bin/date
| The second recipe needs the 'i' flag, since it doesn't actually read
| the message that procmail tries to feed to it.
Ok, now I understand the i flag ;-)
but shouldn't the recipe always fail then? (which it doesn't)
As Phil pointed out already, it has a greater chance of failing with
bigger messages. The write will generate an error when the write
buffer gets full, which is somewhere around 8192 bytes on many
systems. (Could be as low as 1024 or even lower.)
| For consistency with
| the rest of the universe you should probably use "log.gz.lock" as the
| lockfile instead of just "lock" (procmail will choose this name
| automatically if you leave the name of the locallockfile empty, and
| just put the second colon in).
Does it matter? Doesn't it just mean that another process may wait (for no
reason) if it waits for a lock on the file called lock too? Even though it
has to go to a different file.
At the risk of putting words in somebody else's mouth, this is just a
convention. You could begin a C program with
void main (int foo, char **bar)
and nothing would happen but the people who read the source would
wonder why you didn't use the customary argc and argv (and if ole
Murphy gets things his way, you'll forget this at some poiynt yourself
and use the same variable name for something else).
/* era */
Defin-i-t-e-ly. Sep-a-r-a-te. Gram-m-a-r. <http://www.iki.fi/~era/>
* Enjoy receiving spam? Register at <http://www.iki.fi/~era/spam.html>