[comp.mail.sendmail] sendmail sends errors to stdout

diamant@hpfcbig.SDE.HP.COM (John Diamant) (11/29/89)

I recently encountered a fairly annoying defect in sendmail.  It apparently
exists all the way up through BSD 4.3 (I don't know if will be in 4.4).  I'd
like to know what other people think of it.  Below is a description of the
various error processing modes:

          ex          Set error processing to mode x.  Valid modes
                      are:

             m              mail back error messages;

             w              write(2) an error message to the user's
                            terminal if the sender is logged in,
                            otherwise mail it back;

             p              print error messages to standard output
                            (default);

             q              throw away error messages, only indicating
                            failures by returning a non-zero exit
                            status.

Note that mode p (the default) is to print error messages to stdout, rather
than stderr.  This is clearly a violation of the Unix conventions, but
apparently it has been that way for years.  Do all sendmail implementations out
there today still send to stdout instead of stderr?  My problem in this
particular case is a script I run nightly which does something like:

# Regenerate the alias database
/usr/lib/sendmail -bi > /dev/null

I redirect stdout to /dev/null because I don't want to see the status output
message:

461 aliases, longest 580 bytes, 16299 bytes total

every day in my mail from cron (I try to follow the principle that you should
only have reports of items that require attention or are somehow broken).  This
would work correctly for any well-behaved Unix application since I didn't
redirect stderr, but for sendmail, it throws out the error messages.  As a
result, I don't get notified when there are syntax errors in my alias file.

Does this behavior bother anybody else?  If Berkeley didn't fix this, would you
still rather have other Unix suppliers fix it?

Thanks,

John Diamant
Software Engineering Systems Division
Hewlett Packard Co.		ARPA Internet: diamant@hpfclp.sde.hp.com
Fort Collins, CO		UUCP:  {ihnp4!hpfcla,hplabs}!hpfclp!diamant