Wotan suggested,
| I have a simpler suggestion than some others have offered.
Maybe I just don't understand it, but your advice doesn't seem simple to me
at all. This is about using IMAP at my Panix account ... you remember Panix?
I don't want to bore the non-Pancakes on this list with any avoidable detail
-- there's so much here already -- but let's just leave it at this: it's
highly advisable for procmail to know whether an IMAP subfolder exists before
invoking the utility that sends a message over to the IMAP server.
| Create a filter that will do the testing for a file's existence; and add
| some flag to the message. Then write a shell script that will create the
| filter every time you change the list of files.
It sounds to me as though your suggestion means this: every time I add or re-
move a name, run a script to update procmail's list of the names? Well, er,
yes, that's the point. I'd send a control message to my address there to
tell procmail that a certain name is being added or deleted, so it should up-
date its mirror. If you were thinking of a script that sources all the cur-
rently valid names from the IMAP server and refreshes a hash of them that
procmail can see on the shell servers, that can't happen, because nothing
running on a shell server can source the names of currently existing folders
from the IMAP server. Procmail needs to be informed separately of all
changes (except those it generates itself when it gets a message for a folder
that isn't on its list as already existing).
This would all be unnecessary if the IMAP folders were on the same servers
as the shell logins and the procmail processes; then procmail could just run
test -r or something, the fork be damned. There would be no need for a mir-
ror listing nor for control messages to update it. But I can't change their
system.
| Then write your filters for adding/deleting a file; and then one that will
| run the shell script if the files change.
No procmail recipe can possibly tell when the set of existing folders has
changed (much less what the change is when there is one), because procmail
cannot see what is happening on the server where the changes happen. Proc-
mail will have to be told by my control messages. The test for existence I
talked about is one for the folder's name in procmail's mirror listing, not
for the real folder itself. Procmail cannot see directly whether the real
IMAP folder exists. If it could, I wouldn't have this problem.
| Which filters that were used would be dependent on the flag you set.
I have absolutely no idea of what use you have in mind for the flag. Also,
you haven't suggested a format for procmail's mirror.
The idea is to avoid needing to log into a shell to make the update; when I
have another reason to log into a shell anyway, I'll just edit procmail's
mirror listing by hand, but when I don't, I want to update it without needing
to log in.
Thanks for trying to help; unfortunately, we seem to be not just on different
pages here but also on different wavelengths.
I'm going to table this for a while. Thank you again to everyone who has
helped. There might be a general question here worth pursuing: how to main-
tain a mirror listing for procmail's use. But for me, this is on the back
burner now and will stay there for a week or two.
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail