Hi Ken, > If there is ONE bit of code that has caused us a huge amount of > consternation relative to it's use in nmh, it is the db/dbm code. It > is ONLY used by slocal to suppress messages with the same Message-Id.
I had a look. It looks up Message-ID, if found then it verbosely shows its value, if it's not found then it stashes the `Delivery-Date' it built earlier ready for next time. > I asked about removing this feature once, and I only got minor > pushback. While this API is part of POSIX, it doesn't seem like they > are standardized in terms of header files & library names. POSIX, he say #include <ndbm.h>. And there's no special `-l foo' required, unlike for some other include files. http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/ndbm.h.html http://pubs.opengroup.org/onlinepubs/9699919799/utilities/c99.html#tag_20_11_13 That's what configure.ac tries first. dnl Classic ndbm with no library required (eg NetBSD): try this dnl first so we don't accidentally link in a pointless but harmless dnl library in one of the later ndbm.h+libfoo tests: NMH_CHECK_NDBM(ndbm.h,,, dnl Berkeley DBv2 emulating ndbm: header in db.h, e.g., 32-bit Cygwin: NMH_CHECK_NDBM(db.h,db,, dnl Berkeley DBv1 emulating ndbm: NMH_CHECK_NDBM(ndbm.h,db,, NMH_CHECK_NDBM(ndbm.h,db1,, ... > I'd rather make this support conditional; if we can't find a working > db/dbm library then we just don't support duplicate message > suppression. As long as slocal's -(no)suppressdup were errors so the user knew. And a `make check' of it would be good because then of the `skip' in the final count. Would the big `nmh configuration' that's output at the end of ./configure then include whether ndbm.h support was found? It would be handy if more were there, e.g. the recent `ICONV_ENABLED', as it's something the user sees, might even read, and can easily pass onto us. > Also, the implementation seems to have the Message-Id database grow > without bounds, so I have to wonder how much it's being used. Perhaps disk space has kept pace. Or the user sees the `possibly corrupt file' error message and deletes it or otherwise fixes. Given filesystems do a lot better at finding a filename in a large directory these days, and stashing small files within the inode's space, once wonders if Message-ID digested, and stuttered, would be sufficient. Then the user can find(1) on -mtime, etc., to prune, as documented. -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy -- Nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers