[Pyatcron-devel-list] Explanation on the cron time entries (Was: Some comments on Brian code)

[NICOLOVICI Xavier]

Hi everyone,

I love those long thread discussions on specific topics, this is why I love 
open source coding, it makes people think by themselves.

Okay, here is my two cents tip about this */45 cron entry.

According to the Cron documentation, the "/X" is the step that cron should use 
to browse the prepending unit range. In other words, "4-10/2" means start from 
4 and step forward 2 digits until you reach 10. So, the "*/45" entry should 
execute the task every 45 minutes (according that hour entry is "*" of course).

So we might have a problem using arrays of integer to expressed that, but lucky 
we are, Python doesn't really matter about the type of variables. The function 
prototype should expect a list (or array if you prefer), but in Python, a list 
can contain every kind of type, even a mix of different types. According to 
that, the setMinute() function prototype (and the others for hour, date and so) 
should be setMinutes(<list>) and the getMinute() function should return a 
string with the <list> values comma separated. What do you think of that, does 
it sounds good?
On top of that, this comma separated string should be returned by the CronEntry 
class getCommand only. The AtEntry one won't have to deal with interval, as At 
is a "one shot" execution.

Now, the problem I see will be more on the GUI side. We will have to think 
about a way to let the user plan such tasks (every XX minutes, or every YY 
hours). For me, the real problem is here. How the GUI will be designed to allow 
such entries?

Bye,

Xavier

> -----Message d'origine-----
> De : address@hidden
> [mailto:address@hidden
> la part de Childers, Matthew
> Envoyé : mercredi, 19. novembre 2003 00:37
> À : address@hidden
> Objet : RE: [Pyatcron-devel-list] Some comments on Brian code
> 
> 
> > >
> > > I see what you are saying now.  That would work, however, I have a
> > > question more so with cron than how you are saying to do 
> it.  If you
> > > have a minute expressed as */10 that would be run every 10 minutes
> which
> > > could be re-written (10,20,30,40,50,60).  Now if you have a minute
> > > expressed as */45, will this actually run every 45 
> minutes, or only
> on
> > > the 45th minute of the hour?  If it runs every 45 minutes, then I
> don't
> > > know how you would express it in an array, as the minutes would
> change
> > > each hour.  The first hour it would run on the 45th minute, the
> second
> > > hour, on the 30th minute, the third on the 15th minute 
> and so on.  I
> > > looked around and couldn't find any information on this, so if it
> does
> > > not actually run every 45 minutes, then Julien's way would work
> fine,
> > > otherwise, we would have to look at something else.
> > >
> > 
> > Ah yeah. I guess you got a good point here... I thought "*/45" meant
> > "everything except 45" :) As you say, it's just not possible to
> > "emulate" the "*/x" behaviour correctly (provided that cron 
> interprets
> > it correctly) with int arrays. So we'll have to use strings 
> (which is
> > not a problem in fact).
> > 
> 
> 
> Again, I am not certain as to how cron interprets this, so if anyone
> knows, let us know, if not, I will try it tonight and see 
> what it does.
> If it does not interpret it the way I have suggested above, 
> then I think
> the array of integers is the correct way of doing it.
> 
> 
> 
> _______________________________________________
> Pyatcron-devel-list mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/pyatcron-devel-list
> 

This e-mail contains proprietary information some or all of which may be 
legally privileged. It is intended for the recipient only. If an addressing or 
a transmission error has misdirected this e-mail, please notify the author by 
replying to the e-mail. If you are not the intended recipient you must not use, 
disclose, distribute, copy, print, or rely on this e-mail.
We take reasonable precautions to ensure our e-mails are virus free. However, 
we cannot accept responsibility for any virus transmitted by us and recommend 
that you subject any incoming e-mail to your own virus checking procedures.