Sean suggested [I'll respond to Don's post separately when I've had a chance
to reread it],
| grep ^name$ file
As I said, I'm looking for the most efficient way. The check has to be
done for every incoming message, not just for the control messages that
update the listing. Since trying to assign INCLUDERC means no outside
programs, I'm going to stick with that unless someone else comes up with
something better *within* procmail.
So far I have the test part working, including the auto-add if it isn't
there. I haven't done the control message coding yet, because I've yet
to decide what security to use so that it won't be fooled by forged mail
that was not really from me. (A password, I guess, but I would have to
pick the password out and hard-code it into my .procmailrc.)
Right now my .procmailrc sets
varname=!
before the INCLUDERC call. The file itself consists only of
varname<newline>
to unset it, so that a condition of
* $ $varname
back in .procmailrc matches if the name exists and fails if it doesn't.
| ugly:
| grep -v ^text$ file > file.tmp;mv file.tmp file
Very ugly.
ed -s file << \end
/^text$/d
w
q
end
At least then ed handles the temporary file. But rm -f text is so
much cleaner.
| (if using sed, the process would be similar)
Sed would be no improvement over grep.
| If you could always ensure that the last entry is something that would
| always resolve as false, then you could delete the other lines at will
| without having to special case the removal of anything - and anything added
| would always have an '|\' tacked onto the end.
True, and as it is with the hard links I'm using instead, I still need one
under an impossible name so that the file will never completely disappear.
| Coincidentally, the always-false expression would serve as the
| insert-before-anchor for the insertion point for when you're adding new
| lines.
The sequence is not important; new names could be inserted after line 1.
| Why not just write a small c program and call that?
Because I know no C, can't make any sense of the teach-yourself textbooks,
and have no opportunity to take classes in it.
| Arguably, ADD and TEST functionality could be combined (if your process
| runs like "if it isn't there, we'll be adding it") -- simply return a
| status as to whether it was there to begin with or not (and if so, there is
| obviously no need to append a line to the file). Then you're only invoking
| the external process once.
But with a pile of hard links, I don't need to use *any* external process for
a test, only for an add. Like your suggestion, though, attempting to add
that which is already there will result in a nonzero return code from ln.
| You might do is similar for the RM process, though the logic flows
| different there (more efficient if it isn't a burden to read the whole file
| into memory and output it only if you have a match and need to update it).
To rm a hard link I don't need to read any file into memory; the kernel still
has to locate the file, but that would be the same with editing one.
| That gives you ONE program you call, which should have an overhead not much
| different than calling rm or ln, and certainly less clutter if you have
| hundreds or thousands of entries...
I don't understand about clutter. Procmail will have determined the name
from preceding recipes or extractions and stored it in a variable that the
test, add, or delete routine will use. Also, I expect to have at most twenty
entries at a time. All the names will begin with a period so as not to mess
up ls output unless I specify -a to see them.
| Anyway, if you want it to be efficient, perhaps writing a tool to support
| your script is the way to go...
Yes, if I could. Clearly test, ln, and rm include facilities I wouldn't be
using. But I can't write C code, so I'm stuck with programs that are already
written.
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail