Roland Mainz wrote: > Darren J Moffat wrote: >> I'm sponsoring this OpenSolaris case for Chris Gerhard. It has some possible >> standards impact but I believe based on previous discussions this should >> be acceptable, if it wasn't for the standards impact this would likely have >> been self-review. >> >> Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI >> This information is Copyright 2007 Sun Microsystems >> 1. Introduction >> 1.1. Project/Component Working Name: >> crontab entry environment variables >> 1.2. Name of Document Author/Supplier: >> Author: Chris Gerhard >> 1.3 Date of This Document: >> 03 September, 2007 >> 4. Technical Description >> >> This project proposes support for and use of TZ, SHELL and HOME >> variables as per crontab(4) entry varaiables, these are the only ones >> that change the way cron behaves. All others can be achieved via >> having the entry set the variable (SHELL is the weakest of the three to >> change as it only saves on exec). >> >> HOME solves the problems associated with NFS and cronjobs where a users >> home directory is not available when the entry runs (as in the case with >> secure NFS). >> >> TZ obviously sets the time zone when the entry is valid. Allowing jobs >> to run in any time zone. >> >> The variables continue to effect all entries below them until new >> entries are listed in the file. Entries would run with a HOME directory >> set to the one listed and at times that are correct according to the TZ >> value and with a shell specified by SHELL. >> >> Setting any other variable results in an error when you try and save >> the crontab file. >> >> Use of this facility is controlled by an entry in the already existing >> /etc/default/cron [ the project team is aware that ideally this and the >> existing cron(1M) use of this file should migrate to SMF properties but >> that is not this case ]. If there is an entry of the form: >> >> ALLOW_EXTENSIONS=YES > > 1. What will happen if new extensions are added ? IMO this should > include a version number or something similar to make sure syntax > extensions can be added later...
If the knob stays, which the consensus seems to be that it is not required but if it did then versioning could happen when you have the second set of extensions. > > 2. I have great concerns about the abuse of the global environment > variable namespace - sooner or later this will backfire _badly_ if cron > and other applications have slightly different ways to interpret the > values. It would if they did. However since cron is interpreting all the variables in the way you expect I fail to see how this is an issue. TZ is treated as the timezone. If we went with .cron.tz cron would still have to set TZ to match this otherwise you would have a cron job wiht .cron.tz set to PST but running on a system in UTC would have the job seeing time as UTC while scheduled in PST. HOME and SHELL are also being used in their expected ways and again it would be strange to not propagate those in the environment of the cron job having acted on them. --chris
