shore@adobe.UUCP (Andrew Shore) (09/30/85)
Here is a nice little trick I discovered for /usr/lib/crontab.
(All of the following is in 4.2BSD, I don't know how applicable
it is to other systems.) I was always a little frustrated by
the loss of stderr output of cron-invoked shell scripts. If
such scripts break, one hardly ever knows why or how. A few
months ago, after reading Kernighan and Pike's excellent book
"The UNIX Programming Environment", and reviewing the /bin/sh
man page, I realized that the following /bin/sh syntax might
prove helpful:
command args 1>outfile 2>&1
This tells /bin/sh to send stdout (fd==1) to "outfile" and to
make stderr (fd==2) a duplicate of fd 1.
I now have /usr/lib/crontab entries that look like:
1 0 * * * /bin/sh /usr/adm/script.sh 1>/usr/adm/script.log 2>&1
This works like a charm! I get all the stderr output from the
shell executing script.sh and it's descendents. I've never
seen this in anyone else's crontab. Why? Are there any
risks involved? Am I the first person to discover this?
By the way, the man page for cron(8) lies. It says that the
days are numbered 1-7 with 1=Monday. The days are actually
numbered 0-6 with 0=Sunday.
Another gotcha that I have found is as follows. Most systems
start up /etc/cron from /etc/rc. cron and all crontab-entry
invoked processes are children of init (see cron(8) and
init(8)). This can result in a few unexpected results now and
then, since init's environment is not the same as most
getty/login-invoked environments. It is possible to create a
shell script with works just fine from some user's login, but
which breaks when run via crontab. For example, scripts which
use the value of the environment variable USER will break,
since USER is undefined in init's environment. (One solution
might be to set and export USER and other common environment
variables to common and/or harmless values in /etc/rc!)
Now a question for all you gurus and wizards:
The cron(8) manual page says:
"The sixth field is a string that is exe-
cuted by the Shell at the specified times. A percent char-
acter in this field is translated to a new-line character.
Only the first line (up to a % or end of line) of the com-
mand field is executed by the Shell. The other lines are
made available to the command as standard input.
This seems to indicate that a line such as:
1 0 * * * /bin/sh /usr/adm/script.sh 1>/usr/adm/script.log 2>&1
wastes a shell; that it could be run as:
1 0 * * * /usr/adm/script.sh 1>/usr/adm/script.log 2>&1
Since the arguments are fed to a shell anyway. Is this true?
Does /usr/adm/script.sh then have to be executable?
(It isn't now, I obviously haven't tried the alternatives.)
Hope you find my discovery helpful.
--Andy Shore
Adobe Systems Incorporated
{decwrl glacier sun}!adobe!shore
adobe!shore@decwrl.ARPAajs@hpfcla.UUCP (10/04/85)
> This seems to indicate that a line such as: > > 1 0 * * * /bin/sh /usr/adm/script.sh 1>/usr/adm/script.log 2>&1 > > wastes a shell; that it could be run as: > > 1 0 * * * /usr/adm/script.sh 1>/usr/adm/script.log 2>&1 Not only that, you can save another shell by running it as: 1 0 * * * exec /usr/adm/script.sh 1>/usr/adm/script.log 2>&1 I'll be amused if there are systems on which this fails! Alan Silverstein, Hewlett-Packard Fort Collins Systems Division, Colorado {ihnp4 | hplabs}!hpfcla!ajs, 303-226-3800 x3053, N 40 31'31" W 105 00'43"
mikel@codas.UUCP (Mikel Manitius) (10/06/85)
> Here is a nice little trick I discovered for /usr/lib/crontab. > (All of the following is in 4.2BSD, I don't know how applicable > it is to other systems.) I was always a little frustrated by > the loss of stderr output of cron-invoked shell scripts. If > such scripts break, one hardly ever knows why or how. A few > months ago, after reading Kernighan and Pike's excellent book > "The UNIX Programming Environment", and reviewing the /bin/sh > man page, I realized that the following /bin/sh syntax might > prove helpful: > command args 1>outfile 2>&1 > This tells /bin/sh to send stdout (fd==1) to "outfile" and to > make stderr (fd==2) a duplicate of fd 1. > > I now have /usr/lib/crontab entries that look like: > > 1 0 * * * /bin/sh /usr/adm/script.sh 1>/usr/adm/script.log 2>&1 > > This works like a charm! I get all the stderr output from the > shell executing script.sh and it's descendents. I've never > seen this in anyone else's crontab. Why? Are there any > risks involved? Am I the first person to discover this? > > By the way, the man page for cron(8) lies. It says that the > days are numbered 1-7 with 1=Monday. The days are actually > numbered 0-6 with 0=Sunday. > > Another gotcha that I have found is as follows. Most systems > start up /etc/cron from /etc/rc. cron and all crontab-entry > invoked processes are children of init (see cron(8) and > init(8)). This can result in a few unexpected results now and > then, since init's environment is not the same as most > getty/login-invoked environments. It is possible to create a > shell script with works just fine from some user's login, but > which breaks when run via crontab. For example, scripts which > use the value of the environment variable USER will break, > since USER is undefined in init's environment. (One solution > might be to set and export USER and other common environment > variables to common and/or harmless values in /etc/rc!) > > > Now a question for all you gurus and wizards: > > The cron(8) manual page says: > "The sixth field is a string that is exe- > cuted by the Shell at the specified times. A percent char- > acter in this field is translated to a new-line character. > Only the first line (up to a % or end of line) of the com- > mand field is executed by the Shell. The other lines are > made available to the command as standard input. > > This seems to indicate that a line such as: > > 1 0 * * * /bin/sh /usr/adm/script.sh 1>/usr/adm/script.log 2>&1 > > wastes a shell; that it could be run as: > > 1 0 * * * /usr/adm/script.sh 1>/usr/adm/script.log 2>&1 > > Since the arguments are fed to a shell anyway. Is this true? > Does /usr/adm/script.sh then have to be executable? > (It isn't now, I obviously haven't tried the alternatives.) > > Hope you find my discovery helpful. > --Andy Shore > Adobe Systems Incorporated > > {decwrl glacier sun}!adobe!shore > adobe!shore@decwrl.ARPA For all those interrested, in the new release of System V (5.2), if there is any output from a process started by cron, and it is not re-dirrected, it will be mailed to you. -- ======= Mikel Manitius ==----===== AT&T (305) 869-2462 RNX: 755 ==------===== Information Systems ...{akguc|ihnp4}!codas!mikel ===----====== SDSS Regional Support ...attmail!mmanitius =========== Altamonte Springs, FL My opinions are my own. =======
peter@graffiti.UUCP (Peter da Silva) (10/09/85)
> > 1 0 * * * /bin/sh /usr/adm/script.sh 1>/usr/adm/script.log 2>&1 > > 1 0 * * * /usr/adm/script.sh 1>/usr/adm/script.log 2>&1 > 1 0 * * * exec /usr/adm/script.sh 1>/usr/adm/script.log 2>&1 > > I'll be amused if there are systems on which this fails! On V7, not only will that fail, but so will the others. Does anyone know why you can't run a shell script from crontab on V7? Is it just that cron doesn't set up the right environment, or what?
henry@utzoo.UUCP (Henry Spencer) (10/20/85)
> On V7, not only will that fail, but so will the others. Does anyone know why > you can't run a shell script from crontab on V7? Is it just that cron doesn't > set up the right environment, or what? How odd, we are running V7 (Bell Labs V7, not some misnamed mutant which has been hacked to death at some random California university) and we run shell files from crontab all the time. Works fine. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
peter@graffiti.UUCP (Peter da Silva) (10/24/85)
> How odd, we are running V7 (Bell Labs V7, not some misnamed mutant which > has been hacked to death at some random California university) and we run > shell files from crontab all the time. Works fine. In that case some un-named hacker at Tektronix has mucked up cron and/or sh. Thanks a whole hell of a lot. -- Name: Peter da Silva Graphic: `-_-' UUCP: ...!shell!{graffiti,baylor}!peter IAEF: ...!kitty!baylor!peter