Re: mailutils in stretch
On Fri, Jul 07, 2017 at 05:19:45AM -0500, Dave Sherohman wrote:
> On Fri, Jul 07, 2017 at 09:41:33AM +0200, Sven Joachim wrote:
> > There are certainly reasons for that, and I don't think many people
> > use /usr/bin/mail to send or read mail these days.
Huh? I think plenty of locally written shell scripts *do* use "mail"
or "mailx" to send e-mail.
> > Packages using /usr/bin/mail to send reports should depend on, or at
> > least recommend, bsd-mailx | mailx.
It wouldn't be a package. It would be a local shell script.
> The reports in question weren't from packaged reporting tools, but
> rather from random command-line programs being run with a command of the
> form `some-program 2&>1 | mail dave -s "some-program results"`.
Yes, precisely like that. Well, OK, not precisely. You meant 2>&1
and not 2&>1. And the -s subject option should precede the non-option
argument "dave". But otherwise, yeah.
> Is
> there a more "modern"/preferred way of doing this sort of thing, which
> will work in a default stretch install (and doesn't require adding
> headers to the program output to make it suitable for piping directly to
> /usr/sbin/sendmail)?
No, this really is an issue in Debian's package priority choices.
Your script (after patching up the two bugs) is doing the normal,
traditional thing. This is how simple programs have sent e-mail for
decades.
While I'm on this topic, the transition from heirloom-mailx (jessie)
to s-nail (stretch) could have been handled a lot more smoothly.
Programs that want to send e-mail with a MIME attachment can't use
bsd-mailx, so systems using such programs would have installed
heirloom-mailx instead of bsd-mailx. In jessie, both of these packages
provided a program named "mailx". Shell scripts sending e-mail with
MIME attachments would invoke "mailx" to get the job done.
After upgrading to stretch, heirloom-mailx is replaced by s-nail. But
s-nail does *not* provide a program named "mailx". That program is only
provided by bsd-mailx, which cannot create MIME attachments. So, all of
those scripts will break upon upgrading, unless the local sysadmin takes
explicit action -- either rewriting *every* script to call s-nail instead
of mailx, or manually overriding the /etc/alternatives/mailx symlink to
point to /usr/bin/s-nail. Note that s-nail isn't even registered as an
alternative providing mailx, so you can't just use "update-alternatives
--config mailx". Nope. You have to do it manually with ln -sf.
Reply to: