Chris Gerhard wrote:
> Roland Mainz wrote:
> > Chris Gerhard wrote:
> >> Roland Mainz wrote:
> >>> Darren J Moffat wrote:
[snip]
> > Two issues:
> > 1. You basically assign a double-functionality to the variables - they
> > affect both cron internal behaviour and they are exported into the
> > environment of the launched cron job.
> > For example: What do you want to do if you use the timezone "a" for the
> > cron entries but run the cron job with the default system timezone ?
>
> With a crontab entry like this:
>
> TZ=UTC
> * * * 7 * env TZ=PST .....
I really wish the functionality could be cleanly split: One variable
(maybe just written lowercase to indicate that it's affecting local
behvaiour ("local"=this cron instance)) which affects the timezone
selection and a 2nd (written using an uppercase name) which is the
variable which is exported to the environment of the launched process.
> > 2. The scheme as described in the current ARC materials is not
> > extensible since you can't gurantee that you won't create namespace
> > clashes between variables which set/define cron-internal behaviour and
> > stuff which is exported into the environment (imagine you add a variable
> > called "VERSION" to define which version of the cron spec should be used
> > to interpret the cron entries - this would render the OS/Net build
> > defunct since environment variables override Makefile variables and
> > usr/src/Makefile.master contains a variable "VERSION" ... or short:
> > *BOOOOOM* ...).
> > Maybe you could say you only export a defined subset of these variables
> > (e.g. "SHELL", "HOME", "TZ") but that would make these other variables
> > more or less "local variables" and by the usual Unix shell conventions
> > such variable names should be at least spelled using lowercase
> > characters...
>
> I do. The only variables I export are SHELL, HOME and TZ since they are
> the only ones that effect cron. It does not allow the setting of any
> other variables.
What about future extensions ? IMO it would be nice to have a way to
seperate between variables which have only a local meaning and those
which are exported.
For example what happens if you add a variable to set the "project"
(e.g. the project(4) thing) using a "PROJECT" variable (note that the
environment variable "PROJECT" is already in use by other software and
shouldn't be set in an environment (see my easlier concerns about
namespace collisions)) ? What if you want to set a cron-internal
variable (in a later ARC case as extension) which should be exported
(for example one of the very old proposals was a "CRON_SESSION"
environment variable which contains an identifier for the current cron
session and the other idea was "MAILTO" (which leads to the question
whether MAILTO should be exported to the environment of the launched
cron process (which may be usefull) or not)) ?
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
