Re: [Nmh-workers] Locking In Scripts and nmh Locking

[David Levine]

Norm wrote:

> (Minor, and really irrelevant details: send/post imposes
> constraints on and alters the contents of a file; refile
> won't let me designate the name of the destination file;
> refile won't overwrite an existing file; etc,etc. I have
> little doubt that you (David Levine) could figure out ways
> to overcome those details).

nmh-workers, as a whole, will figure out ways to overcome
those details, whether using existing capabilities or adding
new ones.

I'm just trying to help.  Ralph provided a fantastic (and
documented) suggestion of looking at separate mh
environments.  The alternative, locking, requires
cooperation and is therefore tricky to get right, and isn't
robust.  And from what I've seen and experienced in 25
years of using mh, just isn't necessary.

If you can avoid locking, why not?

> >> I don't know which of these things require what kinds
> >> of locking.  I don't want to learn. And most
> >> importantly I shouldn't have to know.
> >
> >I'd much, much rather use the high-level tools.
> >
> >I realize you provided examples so there may be tasks
> >that aren't as easy to handle.  If we need to add to
> >existing programs to get what you need, I think that's
> >the way to go.
>
> The basic philosophy and reason-for-existence of mh and of
> nmh is that that's not the way to go. I should be allowed
> -- nay encouraged -- to use file system tools to
> manipulate mh constructs.

Certainly, I routinely manipulate message files to do all
kinds of things.

Does "mh constructs" include its mechanisms for saving
state?  Not so clear.  As Jerry notes in the section of his
book referenced by Ralph yesterday:

  Worse, the format of public and private sequence files
  isn't documented (as far as I can tell), so it could
  change.

He's not saying "don't do it."  But this is another reason,
along with locking, to stay away from direct manipulation of
mh's state files.

David