Thanks Don,

Comments in line

Don Cragun wrote:
>> However that could leads you to interpreting comments which would be bad.
> Agreed.  I was not suggesting that this exact form is a good idea; only
> that the standards allow comments in crontab files.


However the states:

        Blank lines and those whose first non- <blank> is '#' shall be ignored.

So interpretting the comments would be in breach of the standard as well.

>> Which standard would we be in breach of?
> SVID3, POSIX.1-2001, POSIX.2-1988, XPG3, XPG4, SUS, SUSv2, SUSv3, ...
>> 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.
> Adding anything to the crontab file is going to make it non-portable.
> If the extension to the format can be done in comments in a manner that
> is not likely to be confused with existing comments (and is not likely
> to confuse a human unaware of this extension) then we still conform to
> the standard and at least have comments that can be used to figure out
> what needs to be changed when moving a crontab file to another system.
>> Could we only allow the variables when using /usr/bin/crontab rather 
>> than /usr/xpg[46]/bin/crontab ?
> No.  Each version of crontab supports a subset of the standards listed
> above.  Changing any of them violates one or more standards; picking
> any one of them would just reduce the list of standards being
> violated...

Adding a new one?

/usr/tz/bin/crontab ?

(the path is just an example, I personally dislike this).

All the existing crontab commands would adhere to the standard. If you 
wish to use the extension you use a different crontab command.

Or would we be allowed to have a setting in /etc/default/cron ?


If set you can have the new functionality if not you get the standards 

>> 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.
> I agree that this is the most common case.  If you have a job that is
> to run once every hour, the trick suggested above may be sufficient in
> timezones that are full hours off of GMT.

Not very useful as that does not do day light saving and certainly not 
as nice as just setting the 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.
> The cron daemon isn't honoring any of these, the question is what the
> invoked command will see in the environment after it is invoked by the
> shell cron starts.

Actually the modified cron daemon is honouring the TZ. Having it honour 
HOME as well so that it does not chdir to a directory that may not be 
available (typically due to issues with secure forms of NFS) would also 
be a good thing.


Reply via email to