On Sat, 2017 Mar 18 22:26+0100, Hilko Bengen wrote: > > > Wasn't heirloom-mailx (the predecessor of s-nail) the primary mailx > > provider for Debian? > > No, that must have been bsd-mailx.
Okay, this is fair. I see that heirloom-mailx had "Priority: optional" while bsd-mailx had this at "important". (For my needs, then, bsd-mailx is actually what I want.) > > In any event, h-m originally provided /usr/bin/mail and the upgrade > > path causes this to disappear. Scripts breaking due to mail(1) > > interface variations is a pain, but scripts breaking due to mail(1) > > disappearing altogether is a regression. > > Oh, I see. There are a number of packages which depend on heirloom- > mailx | mailx... Those packages need some grave bugs reported, > then. Damn. I mean, it _is_ right in the name... When I saw in the (current) heirloom-mailx description that "It only contains symlinks to the s-nail binary and manpage," I thought that meant a /usr/bin/mail -> s-nail symlink, which would have been reasonable. But then I saw that the installed symlink was from /usr/bin/heirloom-mailx, which is not very useful. Why not have the transitional heirloom-mailx package provide a /usr/bin/mail symlink? That then gives a reasonable upgrade path and installation option even for new systems. If you just want a mailx-style interface but no /usr/bin/mail, then you just install s-nail. If you want both, then you install heirloom-mailx and s-nail. (This would be like the distinction between the "esmtp" and "esmtp-run" packages. The former provides the actual programs, the latter gives you symlinks for /usr/sbin/sendmail et al.) > > When I read "/usr/bin/mail interface," that implies to me that there > > is a /usr/bin/mail executable. Was the description intended to mean > > something like "mailx-style interface?" > > To be honest, I don't know. I read that as the command-line user > interface one might know from mailx. I think that these days, when few people still use mail(1) interactively, the presence of /usr/bin/mail for the benefit of scripts is a more important point than the style of the interface. IMO, variations like -a are not significant---if one has experience from other Unix systems, they will know that -s is about the only option that can be used reliably anyway.
