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.
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/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
Adding a new one?
(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.