[net.bugs.usg] System V cron problem

jm@wlbr.UUCP (James Macropol) (01/09/86)

System V r2v2 cron neglects to set up the TZ variable in the environment.  As a
result, any forked program that outputs the date defaults to EST5EDT (like
cron=>uucp=>uux=>mail).  Needless to say, this is a bit confusing for us
PST8PDT sites on the west coast.

The same problem existed in System V r0, and System V r2v0.  The following
diffs, however, are accurate only for System Vr2v2.

Jim Macropol
Eaton IMS
{ihnp4,trwrb,scgvaxd,voder,vortex}!wlbr!jm

133a134
> char *getenv();
137a139
> char tznme[50]="TZ=";
139c141
< 	homedir,logname,"PATH=:/bin:/usr/bin:/usr/lbin","SHELL=/bin/sh",0};
---
> 	homedir,logname,"PATH=:/bin:/usr/bin:/usr/lbin","SHELL=/bin/sh",tznme,0};
157a160
> 	char *tzn;
172a176,179
> 
> 	if ((tzn=getenv("TZ")) == 0)
> 		tzn="EST5EDT";
> 	strcat(tznme,tzn);

paul@whuts.UUCP (HO) (01/17/86)

> System V r2v2 cron neglects to set up the TZ variable in the environment. As a
> result, any forked program that outputs the date defaults to EST5EDT (like
> cron=>uucp=>uux=>mail).  Needless to say, this is a bit confusing for us
> PST8PDT sites on the west coast.
> 
> The same problem existed in System V r0, and System V r2v0.  The following
> diffs, however, are accurate only for System Vr2v2.
> 
> Jim Macropol
> Eaton IMS
> {ihnp4,trwrb,scgvaxd,voder,vortex}!wlbr!jm

If you set TZ before you start the cron, and export TZ, then you don't 
need to change the cron. You can do this in /etc/rc, assuming cron is
started there.

	Paul Ho
	..ihnp4!whuts!paul

jm@wlbr.UUCP (James Macropol) (01/20/86)

In article <405@wlbr.UUCP> I write:
>> System V r2v2 cron neglects to set up the TZ variable in the environment.
In article <491@whuts.UUCP> paul@whuts.UUCP (HO) writes:
>If you set TZ before you start the cron, and export TZ, then you don't 
>need to change the cron. You can do this in /etc/rc, assuming cron is
>started there.

This is not true.  cron does NOT pass its environment along to any invoked
program, but constructs an artificial environment, containing only HOME,
LOGNAME, PATH, and SHELL.  Note that TZ is left out.  In order to pass TZ to
invoked programs, two things must be done:

	1) TZ must be set up and exported in the /etc/rc file.
	2) cron must be modified to pass TZ along to invoked programs.

Jim Macropol
Eaton IMS
{ihnp4,scgvaxd,voder,vortex,trwrb,jplgodo}!wlbr!jm

yde@necis.UUCP (David Elins ext. 220) (01/23/86)

In article <409@wlbr.UUCP> jm@wlbr.UUCP (0000-James Macropol) writes:
>
>cron does NOT pass its environment along to any invoked
>program, but constructs an artificial environment, containing only HOME,
>LOGNAME, PATH, and SHELL.  Note that TZ is left out.

I can't speak for other systems, but LOGNAME is not passed on by cron
on our 5.1 SysV68 machine. This was the source of a nasty bug in uucico
(this missing LOGNAME was compounded by a coding error in the uucico code).

A shell script run by cron on our machine showed the following environment:
===== environment / Thu Jan 23 10:00:15 EST 1986 =====
TZ= LOGNAME= SHELL= HOME= PATH=/bin:/etc:/usr/bin

david

paul@whuts.UUCP (HO) (01/27/86)

> In article <405@wlbr.UUCP> I write:
> >> System V r2v2 cron neglects to set up the TZ variable in the environment.
> In article <491@whuts.UUCP> paul@whuts.UUCP (HO) writes:
> >If you set TZ before you start the cron, and export TZ, then you don't 
> >need to change the cron. You can do this in /etc/rc, assuming cron is
> >started there.
> 
> This is not true.  cron does NOT pass its environment along to any invoked
> program, but constructs an artificial environment, containing only HOME,
> LOGNAME, PATH, and SHELL.  Note that TZ is left out.  In order to pass TZ to
> invoked programs, two things must be done:
> 
> 	1) TZ must be set up and exported in the /etc/rc file.
> 	2) cron must be modified to pass TZ along to invoked programs.
> 
> Jim Macropol

You are right and so am I. I looked at the source, and cron was 
already modified to use TZ. For me, I don't have to change the cron,
since we use Bell Labs Division 452 UNIX, and it seems our UNIX
is a little ahead of the official public release. I would *assume*
that bugs like that will eventaully find their way to a later release.

Paul Ho

*** REPLACE THIS LINE WITH YOUR MESSAGE ***