What caused you to think such a thing? Not only is it not true,
it is bass-ackwards. Lockfiles are for delivering to, or processes
that terminate in, files on a local machine where a race condition
could otherwise garble (corrupt) data by overwriting it with a competing
process.
I understand the lockfiles are for delivering as well. I never had an issue
where it would become corrupted. In examples I've always notice the
lockfiles were used for forwarding and hardly used for just delievering to
the spool file.
Okay, so it didn't match. Was that in your netskyd_attach file?
Yes, test.*\.txt was in the netskyd_attach. Except you later go to say that
the dot(s) messes things up (only for fgrep which I was not using). I will
try different combinations to see what I can to do get it to work.
Why did you leave the quotes off? You want the quotes around $MATCH.
If spacing is different, you won't get a match.
The reason why I left off the quotes is because there are no spaces. I can
see in a subject line that would be necessary, but for a file name, you may
have seen it, but I have not seen spaces within it.
Without at least a -w switch or an -x to fgrep, you will get all sorts
of bad matches (false positives). "file" could match "nondefilement";
and so on.
Sorry, I did have the -x option. When I was setting my line back to what it
used to be I forgot to put there.
The -s has nothing to do with spaces. However, depending on what grep
you have compiled, you might indeed want to leave it off:
I also understand what the -s option does. The version I have is:
grep (GNU grep) 2.4d
I have no -I switch in my grep, so I don't have any idea what version
you are running.
Again sorry, this was the act of autocorrect. It is -i and not -I.
If you are using fgrep, you do not use regexs at all; only fixed strings.
So the quote of the dot in your sentence above will cause the match to
fail.
Why do I feel like there has been some miscommunication? I am currently
using fgrep only because I haven't found a way to use external regexs. I
understand that fgrep using fixed strings but with -x it must also match the
line. Using this method means that for every differnce in a file name I must
also list it in the external file. This is why I want to use external regexs
to cut that down. One line can possible match multiple filename, such as
all_document*.pif. (* wildcard).
I understand regexs, but what I can't get to work is matching those regexs.
If I insert what I have in my external list right into procmailrc, it works.
As soon as I use the external file it fails. Even when using the [egrep -wis
-e].
Of course. Put the log call in a nested brace recipe set below what
succeded that you want to log.
So from what you stated I would have a recipe that would look something like
this
:0
* ? [match subject to external "subject" file]
{
:0 B
* ? [match filename to external "attach" file]
{
LOG="[write log]"
:0:
*
/dev/null
}
}
As it is now I would need 12 of these, since I have 12 netsky file lists. I
guess it's time to rethink the file structure.
Thanks dman.
Dan
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail