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
--
Nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers
