At 15:34 2001-07-06 -0500, David W. Tamkin wrote:
As I said, I'm looking for the most efficient way. The check has to be
done for every incoming message,
EVERY incoming message, or only those determined to have some file
attachment (or whatever it is you're checking for)?
At least then ed handles the temporary file. But rm -f text is so
much cleaner.
Note that the add/remove functionality could write to a flat file with a
hardcoded field size (each line being 256 bytes, or whatever you KNOW the
limit for these key names to be, plus newline. The support util would open
the file, read it line by line looking for a match, and when it found one,
rewind to the beginning of that line (conveniently,
recordnumber*recordsize), and overwrite it with a space (or null, etc) at
the first position, which would cause the comparison function to skip that
line. When adding, you'd write your new record into the first empty slot,
or append a new record if there were no deleted records in the file.
| (if using sed, the process would be similar)
Sed would be no improvement over grep.
Wasn't saying it would be. It is of course a bit more versatile for edits.
| 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.
Ah, but my suggestion was that the code for performing the inserion could
copy the input file until it reached the "insert-before" anchor point, make
the insertion, and continue copying (including the anchor). The point is
that nothing else in the file needs to be looked for if you already have a
unique component which conveniently marks the end of the list you're
manipulating.
| 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.
Ok, fair enough. You do have a C compiler available on the server,
right? We can hash out what is necessary to do this, and I could scrawl up
some code for you. If you're interested. If the matches don't involve
regexps (they likely don't if file links would work), then you're looking
at a very light duty little program anyway.
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.
If you're calling ln, or rm, you're calling an external process.
| 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.
Heh, okay, then how about writing a prog and running it as a daemon on some
port? Like a micro-db... Yea, I know, overkill. I was thinking of doing
it for my megagrep at one point though - then I'd load the several hundred
thousand entry AVL tree, and just keep it in memory, instead of loading it
EACH time a message comes in. In my case though, the CPU power is nominal,
and cheap anyway.
I don't understand about clutter.
Links on your drive. But, if you're talking about a score of entries, it
isn't that big a deal.
How often do you expect to CHANGE the links?
All the names will begin with a period so as not to mess
up ls output unless I specify -a to see them.
Hmm, I'd think putting them into a subdir might be slightly cleaner.
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.
As for the thanks - well, thanks, but it's a given amongst those who
frequent this forum that input is appreciated. It's the folks who pop in
and expect someone to create stuff for them because they don't want to read
the manpages that are usually thankless.
---
Sean B. Straw / Professional Software Engineering
Procmail disclaimer: <http://www.professional.org/procmail/disclaimer.html>
Please DO NOT carbon me on list replies. I'll get my copy from the list.
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail