Re: Historical origin of cron's day-of-month/weekday behavior?

2011-10-18 Thread John Abreau
Yes, I know it's a limitation of cron, and that's precisely because
the weekday field does not get ANDed like the other fields.

If the weekday field *was* ANDed with the other fields, it would be
trivially easy to specify "third Wednesday:

0 3 15-21 * 3  /path/to/scipt.sh

This would run at 3:00 AM on every day from the 15th to the
21st that happens to fall on a Wednesday. It's a 7-day span,
so there will only be one Wednesday in the span, and that
Wednesday would be the third Wednesday of the month.

If Brian hadn't made the weekday field behave differently
than the other four fields, then this would work fine. But he
made an extra effort to code it differently, which breaks
this use case.

Since coding the weekday field differently would have taken
extra time and effort, and it complicated a program written by
a man whose core programming philosophy was to keep things
as simple as possible, I'm led to assume that he must have
had a reason to code it differently that overrode his inclination
to keep the program simple and robust.

As for Paul Vixie, he reimplemented cron to behave like the
original AT&T cron. that Brian Kernighan wrote, so I wouldn't
expect Paul to know Brian's thoughts on the matter. But Brian
is still alive, as far as I know, so maybe I can track down his
contact info and ask him directly.



On Tue, Oct 18, 2011 at 11:50 PM, Ken D'Ambrosio  wrote:
> It strikes me that this is a limitation of cron, period -- specifically, the
> lack of "nth occurrence of day of week" field.  Which is why the paragraph you
> quoted ends "One can, however, achieve the desired result by adding a test to
> the command...", said test then being illustrated:
>       0 4 8-14 * *    test $(date +%u) -eq 6 && echo "2nd Saturday"
>
> The fact that he calls it out, with an example of a work-around, makes me 
> think
> that the historical thinking is simple: there wasn't any.  It was -- at least
> to Paul Vixie -- an edge case he hadn't considered when he came up with the
> initial syntax for crontab, and couldn't gracefully retrofit.  That being 
> said,
> everything I just wrote is, obviously, supposition; you could ping Teh Source
> [sic]; I imagine he'd enjoy a query as to his rationale: paul-at-vix-dot-com.
>
> -Ken
>
> On Tue, 18 Oct 2011 23:29:03 -0400 John Abreau  wrote
>
>> My experience is exactly the opposite. I've never run into a situation
>> you describe, but it would be trivially easy to specify it with two
>> cron entries: one specifying Mondays, and the other specifying
>> the first of the month.
>>
>> On the other hand, my "odd case" that you claim is not particularly
>> useful is one that I see all the time. Pretty much every program I've
>> ever seen for scheduling events includes this, cron being the
>> most notable exception. For the few others that lacked it, I recall
>> reading reviews in magazines like PC World giving them bad marks
>> for leaving out the feature. This leads me to believe that I'm not the
>> only person on the planet who finds this functionality particularly useful.
>>
>> If you want other examples other than my user group, my local
>> chapter of Toastmasters meets on the first and third Tuesdays
>> of every month. At my previous job, we had a monthly staff meeting
>> on the fourth Friday of every month. Back when the Boston Computer
>> Society still existed, pretty much every BCS SIG would meet once a
>> month on the n'th $WEEKDAY of the month. Doesn't GNHLUG
>> also schedule its meetings in this manner?
>>
>> In any case, my question was about the original author's reasoning.
>> I've poked around a bit more and learned that Brian Kernighan
>> was the original author, but I still haven't found anything where
>> he explains why he chose that behavior.
>>
>> Did you read somewhere that your use case was actually what
>> Brian had in mind? If so, can you share a link to the article
>> or point me to the book or magazine issue that you read it in?
>>
>>
>>
>> On Tue, Oct 18, 2011 at 10:45 PM, Ken D'Ambrosio  wrote:
>> > Not trying to sound snooty, but this seems so obvious to me that I almost
>> > wonder if I'm missing the point.  All the other fields deal with different
>> > units -- minutes, hours, months.  day-of-month and weekday both apply to
>> > days; so, if you wanted something to execute on both Mondays *and* the
>> > first day of the month (say, a process that ensured that a given week/month
>> > was started afresh), then you'd use both of the fields.  The opposite
> case,
>> > where things are ANDed -- the intersection of the day of the month with the
>> > day of the week -- is an odd enough set that I don't see it being
>> > particularly useful. >
>> > Have I, perhaps, misunderstood something?
>> >
>> > $.02, YMMV, etc.,
>> >
>> > -Ken
>> >
>> >
>> > On Tue, 18 Oct 2011 22:25:31 -0400 John Abreau  wrote
>> >
>> >> One thing that's always annoyed me about cron is how it handles the
>> >> weekday field differently from the other fields. The first four fields,

Re: Historical origin of cron's day-of-month/weekday behavior?

2011-10-18 Thread Ken D'Ambrosio
It strikes me that this is a limitation of cron, period -- specifically, the
lack of "nth occurrence of day of week" field.  Which is why the paragraph you
quoted ends "One can, however, achieve the desired result by adding a test to
the command...", said test then being illustrated:
   0 4 8-14 * *test $(date +%u) -eq 6 && echo "2nd Saturday"

The fact that he calls it out, with an example of a work-around, makes me think
that the historical thinking is simple: there wasn't any.  It was -- at least
to Paul Vixie -- an edge case he hadn't considered when he came up with the
initial syntax for crontab, and couldn't gracefully retrofit.  That being said,
everything I just wrote is, obviously, supposition; you could ping Teh Source
[sic]; I imagine he'd enjoy a query as to his rationale: paul-at-vix-dot-com.

-Ken

On Tue, 18 Oct 2011 23:29:03 -0400 John Abreau  wrote

> My experience is exactly the opposite. I've never run into a situation
> you describe, but it would be trivially easy to specify it with two
> cron entries: one specifying Mondays, and the other specifying
> the first of the month.
> 
> On the other hand, my "odd case" that you claim is not particularly
> useful is one that I see all the time. Pretty much every program I've
> ever seen for scheduling events includes this, cron being the
> most notable exception. For the few others that lacked it, I recall
> reading reviews in magazines like PC World giving them bad marks
> for leaving out the feature. This leads me to believe that I'm not the
> only person on the planet who finds this functionality particularly useful.
> 
> If you want other examples other than my user group, my local
> chapter of Toastmasters meets on the first and third Tuesdays
> of every month. At my previous job, we had a monthly staff meeting
> on the fourth Friday of every month. Back when the Boston Computer
> Society still existed, pretty much every BCS SIG would meet once a
> month on the n'th $WEEKDAY of the month. Doesn't GNHLUG
> also schedule its meetings in this manner?
> 
> In any case, my question was about the original author's reasoning.
> I've poked around a bit more and learned that Brian Kernighan
> was the original author, but I still haven't found anything where
> he explains why he chose that behavior.
> 
> Did you read somewhere that your use case was actually what
> Brian had in mind? If so, can you share a link to the article
> or point me to the book or magazine issue that you read it in?
> 
> 
> 
> On Tue, Oct 18, 2011 at 10:45 PM, Ken D'Ambrosio  wrote:
> > Not trying to sound snooty, but this seems so obvious to me that I almost
> > wonder if I'm missing the point.  All the other fields deal with different
> > units -- minutes, hours, months.  day-of-month and weekday both apply to
> > days; so, if you wanted something to execute on both Mondays *and* the
> > first day of the month (say, a process that ensured that a given week/month
> > was started afresh), then you'd use both of the fields.  The opposite
case,
> > where things are ANDed -- the intersection of the day of the month with the
> > day of the week -- is an odd enough set that I don't see it being
> > particularly useful. >
> > Have I, perhaps, misunderstood something?
> >
> > $.02, YMMV, etc.,
> >
> > -Ken
> >
> >
> > On Tue, 18 Oct 2011 22:25:31 -0400 John Abreau  wrote
> >
> >> One thing that's always annoyed me about cron is how it handles the
> >> weekday field differently from the other fields. The first four fields,
> >> minute, hour, day-of-month, and month, are logically ANDed, but
> >> the day-of-month and weekday fields are ORed.
> >>
> >> The man page describes the behavior, but does not explain the
> >> reasoning behind it:
> >>
> >> >     Note: The day of a command's execution can be specified by two
> >> > fields     -- day of month, and day of week.  If both fields are
> >> > restricted (ie,     are not *), the command will be run when either
> >> > field matches the     current time.  For example, ''30 4 1,15 * 5''
> >> > would cause a command to     be run at 4:30 am on the 1st and 15th of
> >> > each month, plus every Friday. >>
> >> I've looked for an explanation for this in the past, but I've never
> >> had any luck finding one. Making this a special case makes the code
> >> needlessly more complicated and fragile, and it sacrifices useful
> >> functionality; if the weekday had been ANDed like the other fields,
> >> it would be trivially easy to specify things like "third Wednesday
> >> of the month".
> >>
> >>  I'm unable to find or think of a use case that would make the special
> >> behavior useful, and I have to wonder why it was designed this way.
> >>
> >> Can anyone point me to the original author's thoughts on this?
> >>
> >>
> >>
> >> --
> >> John Abreau / Executive Director, Boston Linux & Unix
> >> Email j...@blu.org / WWW http://www.abreau.net / PGP-Key-ID 0xD5C7B5D9
> >> PGP-Key-Fingerprint 72 FB 39 4F 3C 3B D6 5B E0 C8 5A 6E F1 2C BE 99
> >

Re: Historical origin of cron's day-of-month/weekday behavior?

2011-10-18 Thread John Abreau
My experience is exactly the opposite. I've never run into a situation
you describe, but it would be trivially easy to specify it with two
cron entries: one specifying Mondays, and the other specifying
the first of the month.

On the other hand, my "odd case" that you claim is not particularly
useful is one that I see all the time. Pretty much every program I've
ever seen for scheduling events includes this, cron being the
most notable exception. For the few others that lacked it, I recall
reading reviews in magazines like PC World giving them bad marks
for leaving out the feature. This leads me to believe that I'm not the
only person on the planet who finds this functionality particularly useful.

If you want other examples other than my user group, my local
chapter of Toastmasters meets on the first and third Tuesdays
of every month. At my previous job, we had a monthly staff meeting
on the fourth Friday of every month. Back when the Boston Computer
Society still existed, pretty much every BCS SIG would meet once a
month on the n'th $WEEKDAY of the month. Doesn't GNHLUG
also schedule its meetings in this manner?

In any case, my question was about the original author's reasoning.
I've poked around a bit more and learned that Brian Kernighan
was the original author, but I still haven't found anything where
he explains why he chose that behavior.

Did you read somewhere that your use case was actually what
Brian had in mind? If so, can you share a link to the article
or point me to the book or magazine issue that you read it in?



On Tue, Oct 18, 2011 at 10:45 PM, Ken D'Ambrosio  wrote:
> Not trying to sound snooty, but this seems so obvious to me that I almost
> wonder if I'm missing the point.  All the other fields deal with different
> units -- minutes, hours, months.  day-of-month and weekday both apply to days;
> so, if you wanted something to execute on both Mondays *and* the first day of
> the month (say, a process that ensured that a given week/month was started
> afresh), then you'd use both of the fields.  The opposite case, where things
> are ANDed -- the intersection of the day of the month with the day of the week
> -- is an odd enough set that I don't see it being particularly useful.
>
> Have I, perhaps, misunderstood something?
>
> $.02, YMMV, etc.,
>
> -Ken
>
>
> On Tue, 18 Oct 2011 22:25:31 -0400 John Abreau  wrote
>
>> One thing that's always annoyed me about cron is how it handles the
>> weekday field differently from the other fields. The first four fields,
>> minute, hour, day-of-month, and month, are logically ANDed, but
>> the day-of-month and weekday fields are ORed.
>>
>> The man page describes the behavior, but does not explain the
>> reasoning behind it:
>>
>> >     Note: The day of a command's execution can be specified by two fields
>> >     -- day of month, and day of week.  If both fields are restricted (ie,
>> >     are not *), the command will be run when either field matches the
>> >     current time.  For example, ''30 4 1,15 * 5'' would cause a command to
>> >     be run at 4:30 am on the 1st and 15th of each month, plus every Friday.
>>
>> I've looked for an explanation for this in the past, but I've never
>> had any luck finding one. Making this a special case makes the code
>> needlessly more complicated and fragile, and it sacrifices useful
>> functionality; if the weekday had been ANDed like the other fields,
>> it would be trivially easy to specify things like "third Wednesday
>> of the month".
>>
>>  I'm unable to find or think of a use case that would make the special
>> behavior useful, and I have to wonder why it was designed this way.
>>
>> Can anyone point me to the original author's thoughts on this?
>>
>>
>>
>> --
>> John Abreau / Executive Director, Boston Linux & Unix
>> Email j...@blu.org / WWW http://www.abreau.net / PGP-Key-ID 0xD5C7B5D9
>> PGP-Key-Fingerprint 72 FB 39 4F 3C 3B D6 5B E0 C8 5A 6E F1 2C BE 99
>> ___
>> gnhlug-discuss mailing list
>> gnhlug-discuss@mail.gnhlug.org
>> http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
>
>
>
>
>
>



-- 
John Abreau / Executive Director, Boston Linux & Unix
Email j...@blu.org / WWW http://www.abreau.net / PGP-Key-ID 0xD5C7B5D9
PGP-Key-Fingerprint 72 FB 39 4F 3C 3B D6 5B E0 C8 5A 6E F1 2C BE 99

___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/


Re: Historical origin of cron's day-of-month/weekday behavior?

2011-10-18 Thread Ken D'Ambrosio
Not trying to sound snooty, but this seems so obvious to me that I almost
wonder if I'm missing the point.  All the other fields deal with different
units -- minutes, hours, months.  day-of-month and weekday both apply to days;
so, if you wanted something to execute on both Mondays *and* the first day of
the month (say, a process that ensured that a given week/month was started
afresh), then you'd use both of the fields.  The opposite case, where things
are ANDed -- the intersection of the day of the month with the day of the week
-- is an odd enough set that I don't see it being particularly useful.

Have I, perhaps, misunderstood something?

$.02, YMMV, etc.,

-Ken


On Tue, 18 Oct 2011 22:25:31 -0400 John Abreau  wrote

> One thing that's always annoyed me about cron is how it handles the
> weekday field differently from the other fields. The first four fields,
> minute, hour, day-of-month, and month, are logically ANDed, but
> the day-of-month and weekday fields are ORed.
> 
> The man page describes the behavior, but does not explain the
> reasoning behind it:
> 
> > Note: The day of a command's execution can be specified by two fields
> > -- day of month, and day of week.  If both fields are restricted (ie,
> > are not *), the command will be run when either field matches the
> > current time.  For example, ''30 4 1,15 * 5'' would cause a command to
> > be run at 4:30 am on the 1st and 15th of each month, plus every Friday.
> 
> I've looked for an explanation for this in the past, but I've never
> had any luck finding one. Making this a special case makes the code
> needlessly more complicated and fragile, and it sacrifices useful
> functionality; if the weekday had been ANDed like the other fields,
> it would be trivially easy to specify things like "third Wednesday
> of the month".
> 
>  I'm unable to find or think of a use case that would make the special
> behavior useful, and I have to wonder why it was designed this way.
> 
> Can anyone point me to the original author's thoughts on this?
> 
> 
> 
> -- 
> John Abreau / Executive Director, Boston Linux & Unix
> Email j...@blu.org / WWW http://www.abreau.net / PGP-Key-ID 0xD5C7B5D9
> PGP-Key-Fingerprint 72 FB 39 4F 3C 3B D6 5B E0 C8 5A 6E F1 2C BE 99
> ___
> gnhlug-discuss mailing list
> gnhlug-discuss@mail.gnhlug.org
> http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/





___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/


Historical origin of cron's day-of-month/weekday behavior?

2011-10-18 Thread John Abreau
One thing that's always annoyed me about cron is how it handles the
weekday field differently from the other fields. The first four fields,
minute, hour, day-of-month, and month, are logically ANDed, but
the day-of-month and weekday fields are ORed.

The man page describes the behavior, but does not explain the
reasoning behind it:

> Note: The day of a command's execution can be specified by two fields --
> day of month, and day of week.  If both fields are restricted (ie, are
> not *), the command will be run when either field matches the current
> time.  For example, ``30 4 1,15 * 5'' would cause a command to be run at
> 4:30 am on the 1st and 15th of each month, plus every Friday.

I've looked for an explanation for this in the past, but I've never
had any luck finding one. Making this a special case makes the code
needlessly more complicated and fragile, and it sacrifices useful
functionality; if the weekday had been ANDed like the other fields,
it would be trivially easy to specify things like "third Wednesday
of the month".

 I'm unable to find or think of a use case that would make the special
behavior useful, and I have to wonder why it was designed this way.

Can anyone point me to the original author's thoughts on this?



-- 
John Abreau / Executive Director, Boston Linux & Unix
Email j...@blu.org / WWW http://www.abreau.net / PGP-Key-ID 0xD5C7B5D9
PGP-Key-Fingerprint 72 FB 39 4F 3C 3B D6 5B E0 C8 5A 6E F1 2C BE 99
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/


Boston Linux Meeting reminder, tomorrow, October 19, 2011 Usability and Fotoxx

2011-10-18 Thread Jerry Feldman
When: October 19, 2011 7PM (6:30PM for Q&A)
Topic: Usability and Fotoxx
Moderators: Dick and Jill Miller - Miller Microsystems, Inc.
Location: MIT Building E51, Room 325

A discussion of usability, with Fotoxx as an example

Dick and Jill Miller have led Miller Microcomputer Services since 1977,
and think Linux and netbooks are the best yet for most people. They'll
demo Fotoxx on Ubuntu as one powerful yet easy combination for
photography, and think you may want to use it yourself.

Attachments:

Miller Microcomputer Services http://www.millermicro.com/
FOSS User Group in Natick, Ma
http://millermicro.com/FOSSUserGroupNatick.html
Fotoxx home page http://kornelix.squarespace.com/fotoxx

For further information and directions please consult the BLU Web site
http://www.blu.org
Please note that there is usually plenty of free parking in the E-51
parking lot at 2 Amherst St, or directly on Amherst St.

After the meeting we will adjourn to the official after meeting meeting
location at The Cambridge Brewing Company
http://www.cambridgebrewingcompany.com/

-- 
Jerry Feldman 
Boston Linux and Unix
PGP key id:3BC1EB90
PGP Key fingerprint: 49E2 C52A FC5A A31F 8D66  C0AF 7CEA 30FC 3BC1 EB90


___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/


Re: VPN only session.

2011-10-18 Thread Brian St. Pierre
On Mon, Oct 17, 2011 at 1:46 PM, Alan Johnson  wrote:
> On Oct 16, 2011 10:14 AM, "Greg Kettmann"  wrote:
>>
>> The problem is that the VPN session randomly drops out.  Basically, I
>> start Ubuntu and once it's operational I click on the little up/down
>> arrows for network.  I select the VPN and I activate it.  This puts a
>> little lock on the up/down arrows and I'm set.  Sometimes the lock drops
>> off and I'm sending (or trying to send) in the clear.  Easy enough to
>> fix but often a pain to get things back to the proper state.
>>
>> What I would prefer is to have the VMware session just be connected via
>> VPN... no VPN, no connectivity.  If the VPN connection drops out I don't
>> want it to fall back down to sending in the clear.  The whole session
>> will stop working and I can restart it.  Is that possible?  I've tried
>> searching on this, without much luck, but perhaps my search arguments
>> are bad.  I'm not married to Ubuntu nor to VMware player.  If some other
>> combination is known to work I'd love to hear about it.
>
> I don't think there is a way to do that directly in the network config.
> Besides, your local connection has to be active to enable connecting to the
> VPN anyway.  You could turn off dhcp for your local connection in the vm and
> manually configure it without dns servers, then name resolution would only
> work if you were connected to your VPN.  Browsers will still cache some
> names, but that usually times out pretty quickly.  You'd also want to add
> your VPN server to /etc/hosts but that can be annoying if the IP address
> changes.  This also won't help if you access much by VPN.

Turning off DHCP seems like it is on the right track.

I haven't tested this, but I think you could edit the routes in the
network manager so that your primary network interface only has a
route to your VPN server.

Right click the network icon, Edit Connections..., select your primary
interface, Edit..., IPv4 Settings tab, Routes..., Add. Enter the IP of
your VPN server, use 255.255.255.255 for the netmask, and the IP
address of your default gateway.

Verify the settings are correct by rebooting the VM and running "route
-n" in a terminal. You should see just one line -- for your VPN
server, and no default route (destination 0.0.0.0). Try pinging your
VPN server (should work), then try pinging some other address (should
fail). Then bring up the VPN and all should work as normal. Then kill
the VPN and everything should fail.

This should make it so you don't accidentally send traffic in the
clear, but it won't auto-restart your VPN session. You might be able
to do something with a script that runs when the interface goes down,
but I'm foggy on the details.

-Brian

___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/