Re: [Nmh-workers] slocal(1) and its dbm_open(3) Use.

[Ralph Corderoy]

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