2000-03-06-06:33:06 Sebastian Helms:
I tried including these two for all messages, that is, without a
|perl -ple 's/^\s+//;s/\s+$//;s/\s+/ /g'|uniq
|perl -ple 's/^(.)\1\1\1+$/\1\1\1/'
Whoops! I should add here, that I don't do that sort of munging in
procmail, and wouldn't advocate it there; I'm a keen fan of keeping
email transport as transparent as possible. For very specific
examples of problems, if you do that sort of munging then you'll run
a very real risk of breaking PGP signatures.
I do that sort of cleaning up when I'm taking a message and
preparing it to download to a palm. But do you really want to e.g.
trash all leading whitespace (the very first subst in that first
perl I gave) for all email? That will break continued header lines,
Now, my log shows:
procmail: Executing "perl -ple 's/^\s+//;s/\s+$//;s/\s+/ /g'|uniq"
procmail: Executing "perl,-ple,s/^(.)\1\1\1+$/\1\1\1/"
My question is, why are there commas in the second entry ? Do I have
to wonder ? Should I change something ?
The first recipe is a pipeline of two commands; it has an unquoted
"|" character. So from procmail's point of view, it's not a simple
command, it's a complex shell command, so procmail takes the entire
thing and feeds it as a single wad to the shell, for it to
The second command is a simple command, an executable name (to
be found on the PATH) followed by a series of arguments, with no
special shell funky stuff going on. So procmail handles it itself,
directly. So you see the comments where procmail has separated the
line into arguments before feeding the bits to execvp(3) or one of
Description: PGP signature