SUMMARY: /usr/bin/at question

From: <Frank_DeMontier_at_ssga.com>
Date: Wed Jan 09 2002 - 07:40:02 EST
Many thanks to all who replied ( and in a timely manner ) I might add:

Allan West
John Benjamins
Michael Maciolek
Jesse Trucks
Eric Horne
Mark Hargrave
Justin Stringfellow
Paul LaMadeleine
Srinivas_Arella

The general ( unanimous ) consensus is that the redirection WILL work if
done properly. A few samples from the replies:

(BTW, it appears the problem here may be "environment" related...)

#######################################################################################
at and crontabs are both evaluated by the ksh shell on my system (and
presumably on yours) so you can either make jobs which produce no output or

dump the output to /dev/null with the ksh syntax:
           /path/to/script > /dev/null 2>&1
which sends stderr (#2) to stdout (#1) and dumps stdout to /dev/null
##############################################################################

Redirection _does_ work, as long as it's catching everything.
However, if even a single byte is sent to either stdout or stderr,
then 'at' will send an email.

The obvious thing to do is examine the email that 'at' is sending.
If it seems to be blank, examine it very carefully for whitespace -
perhaps an extra newline.

Prove to yourself that 'at' is indeed silent when there is no output.

This should generate no email:
           at 'now + 1 minute' <<EOT
           touch /tmp/abc
           EOT

and this should generate a 1-line message:
           at 'now + 1 minute' <<EOT
           date
           EOT
##############################################################################################

It is my belief that at (and cron) will not send mail unless there is
output from the command(s) it is executing. So you need to make sure
that the program's output is being redirected -- both STDOUT and STDERR:

           foo > /dev/null 2>&1

  Also note that if you redirect STDERR to STDOUT before redirecting
STDOUT, you will still get STDERR output.. In other words, "foo 2>&1 >
/dev/null" will cause STDOUT to go to /dev/null (good), but will cause
STDERR to go to whatever STDOUT was before it went to /dev/null -- so
you will still get output if the program prints to STDERR.
#####################################################################################


Thanks again to all.


Buddy DeMontier
SSgA
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers
Received on Wed Jan 9 06:41:11 2002

This archive was generated by hypermail 2.1.8 : Thu Mar 03 2016 - 06:42:31 EST