I challenge anyone to _not_ duplicate this behavior.

courier sendmail fails and _without_logging_ when called by atd to mail output from a root at job.

Tim Lynch wrote: : Sam Varshavchik wrote: : >> > Try putting the following nonsense before the command: : >> > : >> > exec >/dev/null; exec 2>/dev/null; exec 1</dev/null; : ... : > You're not sinking anything to /dev/null. The above should be followed : > by whatever you want to run, with its output piped to Courier's sendmail. : ^^^^^^^^^^^^^^^^^^^^^ : ah, you mean like this: : # batch <<eof : exec >/dev/null; exec 2>/dev/null; exec 1</dev/null; : ( echo 'the date is:'; date ; ls /tmp/ENOENT ) 2>&1 | sendmail root : eof : : yes, piping output to sendmail works. but such piping obviates : rearranging the fd's with exec, although 2>&1 for the subshell before : the pipe catches the stderr about ENOENT. i would pipe to ``mail -s : output root'' instead of directly to sendmail. having the job send : output instead of letting atd send the output is a useful workaround. : : however the courier sendmail replacement appears to fail when called by : atd to send the output of a root batch job. actual sendmail does not : fail. anyone else see this behavior?