Don Cragun wrote:
> Roland, 
>       Thanks for bringing this to my attention.
> 
> Chris,
>       The format shown in
> http://blogs.sun.com/chrisg/entry/mutliple_time_zones_for_cron is not
> allowed by the current standards.  The standards say that entries in
> crontab files are of three types:
> 1.  Blank lines  (i.e., spaces and tabs only terminated by a newline)
> 2.  Comment lines (i.e., lines whose first non-blank character is '#')
> 3.  The standard 6 field crontab entry specifying the minute, hour, day
>     of month, month of year, day of week, and command to be executed by
>     the shell.
> So, lines like:
> TZ=GMT
> and
> TZ=US/Pacific
> are not allowed.
>       But, since lines like:
> # TZ=GMT
> and
> # TZ=US/Pacific
> are allowed by the standard, you can do the same thing in a manner
> compatible with the standard.

However that could leads you to interpreting comments which would be bad.

Which standard would we be in breach of?

It seems that the choices being offered are:

1) Go with my suggestion. Which at least to me seems the most clear.
2) Add the variables to comments which could lead to us interpreting 
existing crontab files incorrectly if they already contain:

# TZ= ....

and if we were to add other variables, HOME being one that would be 
truly useful as I mentioned in another email in the thread. We end up 
with a poorer user experience while complying to a standard that would 
allow a customer to copy the crontab file to another system.

Could we only allow the variables when using /usr/bin/crontab rather 
than /usr/xpg[46]/bin/crontab ?


>       For the record, I have also seen suggestions lately that $SHELL
> should affect the shell used to run cron jobs.  The standard also says
> that this is not allowed.  The values of $HOME, $LOGNAME, $PATH, $SHELL
> and, although not explicitly mentioned, $TZ in the environment
> inherited by crontab are not allowed to be used by default.  But this
> can be done and still meet standards requirements by using
> implementation specific extensions such as command line options.  I.e.,
> the standard allows for option to be specified when crontab is invoked
> to add a cron job.  So, something like:
>               crontab [-H HOME_value] [-L LOGNAME_value] \
>                       [-P PATH_value] [-S SHELL_value] \
>                       [-T TZ_value] [file]
> would be legal and the values specified could be stored as comments in
> the crontab file.
>       Note also that a lot of this can be done today with no changes
> to cron or crontab.  You can set TZ in the environment of the command
> to be executed using the following form:
> * 8 * * * TZ=US/Eastern date > /tmp/out8
> which will write a date stamp to the console every minute of the 8
> o'clock hour of the local timezone displayed with US Eastern Time Zone
> time stamps.  It is trickier when using subshells as in your example
> where you would have to use:
> * 8 * * * TZ=US/Eastern;export TZ;(/usr/bin/date ; /usr/bin/date -u) > 
> /tmp/cron.out8
> if you're using /usr/bin/crontab to add the job.  /usr/bin/crontab uses
> a SVID3 compatible shell which does not support variable assignment in
> an export statement.  If you're using /usr/xpg4/bin/crontab or
> /usr/xpg6/bin/crontab, the same crontab entry could be written as:
> * 8 * * * export TZ=US/Eastern;(/usr/bin/date ; /usr/bin/date -u) > 
> /tmp/cron.out8
>       Whether you would want to use this form obviously depends on
> whether you want the time at which the command will be executed and the
> output of commands run to be controlled by the alternate TZ setting, or
> you just want the output of the commands run to be controlled by the
> alternate TZ setting.

The TZ actually needs to work on within cron so that the time of the 
event is run at the correct time according to that timezone.

The extra variables are potentially useful when they effect cron.  TZ & 
HOME and to a lesser degree SHELL & PATH (since you can do this with a 
script). I fail to see the usefulness of allowing the setting of LOGNAME 
since cron would clearly not honour this.

--chris

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3253 bytes
Desc: S/MIME Cryptographic Signature
URL: 
<http://mail.opensolaris.org/pipermail/request-sponsor/attachments/20070213/402375d6/attachment.bin>

Reply via email to