Re: [Nmh-workers] 1.7's `make clean' is Overzealous.

[Ralph Corderoy]

Hi Ken,

I'm catching up on the list.  It's a bit weird.  Disagreement and I'm
hardly involved.  :-)

> >    If your program installs a large number of files into one of the
> >    standard user-specified directories, it might be useful to group
> >    them into a subdirectory particular to that program.  If you do
> >    this, you should write the install rule to create these
> >    subdirectories.
>
> I understand their point, but we could say the same thing about
> $(bindir) and I don't think anyone is suggesting we default to
> installing all of the executables in $(bindir)/nmh (unless maybe we
> are?).

Well, proprietary Unixes that shipped MH did put it in /usr/bin/mh and
require the user to augment PATH to use it.  IBM's AIX did.  There was
another, perhaps DEC's Ultrix?  I forget.  And that was with less than
today's 46 commands.

    ali          folders      mhlist       new          rmm
    anno         forw         mhlogin      next         scan
    burst        fprev        mhmail       packf        send
    comp         inc          mhn          pick         sendfiles
    dist         install-mh   mhparam      prev         show
    flist        mark         mhpath       prompter     sortm
    flists       mhbuild      mhshow       refile       unseen
    fmttest      mhfixmsg     mhstore      repl         whatnow
    fnext        mhical       msgchk       rmf          whom
    folder

Some of these aren't worthy of polluting /usr/bin IMHO and should have
been private ~/bin scripts the call a command with options, e.g.
fnext(1) describes itself as equivalent to `new -mode fnext'.  new(1)
itself seems a bit too generic a name.  Anyway, digression.  Point is,
historically, $(bindir)/mh was used.

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy