[Phpwm] Cron.monthly

[Chris Allen]

I have a question or three regarding cron:

On debian, am I right in thinking that in order to run a php script every 
month, I just copy the file into the cron.monthly folder? ( I'll stick with 
the global date/time settings for now.)
Are there any naming conventions apart from the fact it has to be lowercase?
Also if I want to run the file in the cron.monthly folder to test it, what 
would I type?

Thanks,

Chris.


>From: phpwm-request at mailman.lug.org.uk
>Reply-To: phpwm at mailman.lug.org.uk
>To: phpwm at mailman.lug.org.uk
>Subject: Phpwm Digest, Vol 58, Issue 5
>Date: Tue, 20 Mar 2007 13:12:50 +0000
>
>Send Phpwm mailing list submissions to
>	phpwm at mailman.lug.org.uk
>
>To subscribe or unsubscribe via the World Wide Web, visit
>	https://mailman.lug.org.uk/mailman/listinfo/phpwm
>or, via email, send a message with subject or body 'help' to
>	phpwm-request at mailman.lug.org.uk
>
>You can reach the person managing the list at
>	phpwm-owner at mailman.lug.org.uk
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of Phpwm digest..."
>
>
>If you reply to this 'Digest' email, please change the subject to reflect 
>the post you are replying to.
>
>If you wish to earn more Brownie points,
>please trim / remove irrelevant posts and content, to keep the conversation 
>clear :)
>
>
>Today's Topics:
>
>    1. RE: Cleaning up addresses (Phil Beynon)
>    2. RE: Cleaning up addresses (Dave Holmes)
>    3. RE: Cleaning up addresses (Phil Beynon)
>    4. RE: Cleaning up addresses (Mike Tipping)
>    5. RE: Cleaning up addresses (Dave Holmes)
>
>
>----------------------------------------------------------------------
>
>Message: 1
>Date: Tue, 20 Mar 2007 12:15:43 -0000
>From: "Phil Beynon" <phil at infolinkelectronics.co.uk>
>Subject: RE: [Phpwm] Cleaning up addresses
>To: "West Midlands PHP User Group" <phpwm at mailman.lug.org.uk>
>Message-ID:
>	<MDBBIMBGKCJEJKIHMENGCEOEOEAA.phil at infolinkelectronics.co.uk>
>Content-Type: text/plain;	charset="iso-8859-1"
>
>Hi Dave,
>
> > I thought so Phil, my original assumption is correct this can be 
>achieved
> > very easily as I have implemented just this functionality in a number of
> > sites, one of which is now maintained by Darren @ siftware. Basically 
>they
> > have a trader register which allows the user to enter their postcode and
> > search for a builder for example.
> >
> > The system them runs a query on the database to generate a list of 
>traders
> > showing the closest first with an approximate distance, all of
> > this was done
> > by the trader simply entering their postcode when they register. i.e. 
>the
> > whole thing works based on postcode proximity.
>
>Thats another way of doing it I agree, though there are a few situations
>where mine is going to definitely work better.
>
> > To achieve this you need a file which can be licensed for £500 at
> > a reseller
> > rates
>
>Where from?
>
> > then you just need a source postcode and postcode of the traders in
> > the MySQL snip below table d is the search origin postcode and the table 
>e
> > is a company or your example traders postcode, results can be filtered 
>to
> > the most appropriate by ordering on distance and then using the limit
> > statement.
>
>Sure, I can see thats cheaper and less labour intensive than the way we did
>it. :-)
>We relied on multimap for distances / directions.
>
> > <MySQL>
> >
> > (acos(sin(radians(d.latitude)) * sin(radians(e.latitude)) +
> > cos(radians(d.latitude)) * cos(radians(e.latitude)) *
> > cos(radians(d.longitude) - radians(e.longitude)))) * 3437.7387 *
> > 1.150779 as
> > mileage
> >
> > </MySQL>
> >
> > Took around a day to get the search working right and this is something 
>I
> > have used time and time again to provide proximity stuff for my clients.
> >
> > More importantly the results are generated in milliseconds using a 
>single
> > query
>
>This was one query per postcode expansion, since you have to individually
>run the math on all your table entries to get the distances I'm not sure in
>a big database which would be faster, yours would certainly give the server
>a bigger memory spike which on a busy site could be noticeable.
>
>If I was doing it your way I think I would want to pre-generate a postcode
>exclusion table based on exceeding a certain distance.
>
>Phil
>
>
>
>
>------------------------------
>
>Message: 2
>Date: Tue, 20 Mar 2007 12:30:58 -0000
>From: "Dave Holmes" <dave at neteffekt.co.uk>
>Subject: RE: [Phpwm] Cleaning up addresses
>To: "'West Midlands PHP User Group'" <phpwm at mailman.lug.org.uk>
>Message-ID: <046d01c76aeb$9db78f60$d926ae20$@co.uk>
>Content-Type: text/plain;	charset="iso-8859-1"
>
>You can get the file from a company call kings wood map mechanics and the
>file is called the code point file.
>
>Server spike is negligible as MySQL eats the maths and in real terms there
>are not that many recs. We are doing a lot more heavy duty processing on 
>the
>satellite tracking software we have created which handles loads of
>concurrent connections from devices communicating via Data calls, SMS and
>GPRS. No performance worries yet. Then again it is running across 6 servers
>all of which are dual xeons with bags of ram.
>
>
>-----Original Message-----
>From: phpwm-bounces at mailman.lug.org.uk
>[mailto:phpwm-bounces at mailman.lug.org.uk] On Behalf Of Phil Beynon
>Sent: 20 March 2007 12:16
>To: West Midlands PHP User Group
>Subject: RE: [Phpwm] Cleaning up addresses
>
>Hi Dave,
>
> > I thought so Phil, my original assumption is correct this can be 
>achieved
> > very easily as I have implemented just this functionality in a number of
> > sites, one of which is now maintained by Darren @ siftware. Basically 
>they
> > have a trader register which allows the user to enter their postcode and
> > search for a builder for example.
> >
> > The system them runs a query on the database to generate a list of 
>traders
> > showing the closest first with an approximate distance, all of
> > this was done
> > by the trader simply entering their postcode when they register. i.e. 
>the
> > whole thing works based on postcode proximity.
>
>Thats another way of doing it I agree, though there are a few situations
>where mine is going to definitely work better.
>
> > To achieve this you need a file which can be licensed for £500 at
> > a reseller
> > rates
>
>Where from?
>
> > then you just need a source postcode and postcode of the traders in
> > the MySQL snip below table d is the search origin postcode and the table 
>e
> > is a company or your example traders postcode, results can be filtered 
>to
> > the most appropriate by ordering on distance and then using the limit
> > statement.
>
>Sure, I can see thats cheaper and less labour intensive than the way we did
>it. :-)
>We relied on multimap for distances / directions.
>
> > <MySQL>
> >
> > (acos(sin(radians(d.latitude)) * sin(radians(e.latitude)) +
> > cos(radians(d.latitude)) * cos(radians(e.latitude)) *
> > cos(radians(d.longitude) - radians(e.longitude)))) * 3437.7387 *
> > 1.150779 as
> > mileage
> >
> > </MySQL>
> >
> > Took around a day to get the search working right and this is something 
>I
> > have used time and time again to provide proximity stuff for my clients.
> >
> > More importantly the results are generated in milliseconds using a 
>single
> > query
>
>This was one query per postcode expansion, since you have to individually
>run the math on all your table entries to get the distances I'm not sure in
>a big database which would be faster, yours would certainly give the server
>a bigger memory spike which on a busy site could be noticeable.
>
>If I was doing it your way I think I would want to pre-generate a postcode
>exclusion table based on exceeding a certain distance.
>
>Phil
>
>
>_______________________________________________
>Phpwm mailing list
>Phpwm at mailman.lug.org.uk
>https://mailman.lug.org.uk/mailman/listinfo/phpwm
>
>
>
>
>------------------------------
>
>Message: 3
>Date: Tue, 20 Mar 2007 12:52:12 -0000
>From: "Phil Beynon" <phil at infolinkelectronics.co.uk>
>Subject: RE: [Phpwm] Cleaning up addresses
>To: "West Midlands PHP User Group" <phpwm at mailman.lug.org.uk>
>Message-ID:
>	<MDBBIMBGKCJEJKIHMENGEEOHOEAA.phil at infolinkelectronics.co.uk>
>Content-Type: text/plain;	charset="iso-8859-1"
>
> > You can get the file from a company call kings wood map mechanics and 
>the
> > file is called the code point file.
>
>I shall file that away for future referance!
>
> > Server spike is negligible as MySQL eats the maths and in real terms 
>there
> > are not that many recs. We are doing a lot more heavy duty
> > processing on the
> > satellite tracking software we have created which handles loads of
> > concurrent connections from devices communicating via Data calls, SMS 
>and
> > GPRS. No performance worries yet. Then again it is running across
> > 6 servers
> > all of which are dual xeons with bags of ram.
>
>Fair enough - my development machine is a Raq4, so its not quite in the 
>same
>class performance wise - but that does keep me ontrack for keeping things
>resource efficient :-)
>
>I can see the way you have done it is quite fast and accurate, but at the
>same time it is very metrocentric in its nature which is its main failing,
>whereas my method is probably slightly slower but doesn't have that 
>inherent
>disadvantage, so in theory should be presenting a better result set.
>
>Phil
>
> >
> >
> > -----Original Message-----
> > From: phpwm-bounces at mailman.lug.org.uk
> > [mailto:phpwm-bounces at mailman.lug.org.uk] On Behalf Of Phil Beynon
> > Sent: 20 March 2007 12:16
> > To: West Midlands PHP User Group
> > Subject: RE: [Phpwm] Cleaning up addresses
> >
> > Hi Dave,
> >
> > > I thought so Phil, my original assumption is correct this can
> > be achieved
> > > very easily as I have implemented just this functionality in a number 
>of
> > > sites, one of which is now maintained by Darren @ siftware.
> > Basically they
> > > have a trader register which allows the user to enter their postcode 
>and
> > > search for a builder for example.
> > >
> > > The system them runs a query on the database to generate a list
> > of traders
> > > showing the closest first with an approximate distance, all of
> > > this was done
> > > by the trader simply entering their postcode when they
> > register. i.e. the
> > > whole thing works based on postcode proximity.
> >
> > Thats another way of doing it I agree, though there are a few situations
> > where mine is going to definitely work better.
> >
> > > To achieve this you need a file which can be licensed for £500 at
> > > a reseller
> > > rates
> >
> > Where from?
> >
> > > then you just need a source postcode and postcode of the traders in
> > > the MySQL snip below table d is the search origin postcode and
> > the table e
> > > is a company or your example traders postcode, results can be
> > filtered to
> > > the most appropriate by ordering on distance and then using the limit
> > > statement.
> >
> > Sure, I can see thats cheaper and less labour intensive than the
> > way we did
> > it. :-)
> > We relied on multimap for distances / directions.
> >
> > > <MySQL>
> > >
> > > (acos(sin(radians(d.latitude)) * sin(radians(e.latitude)) +
> > > cos(radians(d.latitude)) * cos(radians(e.latitude)) *
> > > cos(radians(d.longitude) - radians(e.longitude)))) * 3437.7387 *
> > > 1.150779 as
> > > mileage
> > >
> > > </MySQL>
> > >
> > > Took around a day to get the search working right and this is
> > something I
> > > have used time and time again to provide proximity stuff for my 
>clients.
> > >
> > > More importantly the results are generated in milliseconds
> > using a single
> > > query
> >
> > This was one query per postcode expansion, since you have to 
>individually
> > run the math on all your table entries to get the distances I'm
> > not sure in
> > a big database which would be faster, yours would certainly give
> > the server
> > a bigger memory spike which on a busy site could be noticeable.
> >
> > If I was doing it your way I think I would want to pre-generate a 
>postcode
> > exclusion table based on exceeding a certain distance.
> >
> > Phil
> >
> >
> > _______________________________________________
> > Phpwm mailing list
> > Phpwm at mailman.lug.org.uk
> > https://mailman.lug.org.uk/mailman/listinfo/phpwm
> >
> >
> > _______________________________________________
> > Phpwm mailing list
> > Phpwm at mailman.lug.org.uk
> > https://mailman.lug.org.uk/mailman/listinfo/phpwm
> >
>
>
>
>
>------------------------------
>
>Message: 4
>Date: Tue, 20 Mar 2007 12:55:55 -0000
>From: "Mike Tipping" <mike at e-msg.co.uk>
>Subject: RE: [Phpwm] Cleaning up addresses
>To: "'West Midlands PHP User Group'" <phpwm at mailman.lug.org.uk>
>Message-ID: <E1HTdt4-0003Wb-00 at xinit.lug.org.uk>
>Content-Type: text/plain;	charset="iso-8859-1"
>
>Google maps API now allows you to geo code UK addresses to Lat longs so
>there is no need to use a licensed file - unless you need the resilience of
>not using something that will be in beta for ever more.
>
>Cheers
>
>Mike
>
>-----Original Message-----
>From: phpwm-bounces at mailman.lug.org.uk
>[mailto:phpwm-bounces at mailman.lug.org.uk] On Behalf Of Dave Holmes
>Sent: 20 March 2007 12:31
>To: 'West Midlands PHP User Group'
>Subject: RE: [Phpwm] Cleaning up addresses
>
>You can get the file from a company call kings wood map mechanics and the
>file is called the code point file.
>
>Server spike is negligible as MySQL eats the maths and in real terms there
>are not that many recs. We are doing a lot more heavy duty processing on 
>the
>satellite tracking software we have created which handles loads of
>concurrent connections from devices communicating via Data calls, SMS and
>GPRS. No performance worries yet. Then again it is running across 6 servers
>all of which are dual xeons with bags of ram.
>
>
>-----Original Message-----
>From: phpwm-bounces at mailman.lug.org.uk
>[mailto:phpwm-bounces at mailman.lug.org.uk] On Behalf Of Phil Beynon
>Sent: 20 March 2007 12:16
>To: West Midlands PHP User Group
>Subject: RE: [Phpwm] Cleaning up addresses
>
>Hi Dave,
>
> > I thought so Phil, my original assumption is correct this can be 
>achieved
> > very easily as I have implemented just this functionality in a number of
> > sites, one of which is now maintained by Darren @ siftware. Basically 
>they
> > have a trader register which allows the user to enter their postcode and
> > search for a builder for example.
> >
> > The system them runs a query on the database to generate a list of 
>traders
> > showing the closest first with an approximate distance, all of
> > this was done
> > by the trader simply entering their postcode when they register. i.e. 
>the
> > whole thing works based on postcode proximity.
>
>Thats another way of doing it I agree, though there are a few situations
>where mine is going to definitely work better.
>
> > To achieve this you need a file which can be licensed for £500 at
> > a reseller
> > rates
>
>Where from?
>
> > then you just need a source postcode and postcode of the traders in
> > the MySQL snip below table d is the search origin postcode and the table 
>e
> > is a company or your example traders postcode, results can be filtered 
>to
> > the most appropriate by ordering on distance and then using the limit
> > statement.
>
>Sure, I can see thats cheaper and less labour intensive than the way we did
>it. :-)
>We relied on multimap for distances / directions.
>
> > <MySQL>
> >
> > (acos(sin(radians(d.latitude)) * sin(radians(e.latitude)) +
> > cos(radians(d.latitude)) * cos(radians(e.latitude)) *
> > cos(radians(d.longitude) - radians(e.longitude)))) * 3437.7387 *
> > 1.150779 as
> > mileage
> >
> > </MySQL>
> >
> > Took around a day to get the search working right and this is something 
>I
> > have used time and time again to provide proximity stuff for my clients.
> >
> > More importantly the results are generated in milliseconds using a 
>single
> > query
>
>This was one query per postcode expansion, since you have to individually
>run the math on all your table entries to get the distances I'm not sure in
>a big database which would be faster, yours would certainly give the server
>a bigger memory spike which on a busy site could be noticeable.
>
>If I was doing it your way I think I would want to pre-generate a postcode
>exclusion table based on exceeding a certain distance.
>
>Phil
>
>
>_______________________________________________
>Phpwm mailing list
>Phpwm at mailman.lug.org.uk
>https://mailman.lug.org.uk/mailman/listinfo/phpwm
>
>
>_______________________________________________
>Phpwm mailing list
>Phpwm at mailman.lug.org.uk
>https://mailman.lug.org.uk/mailman/listinfo/phpwm
>
>
>
>
>
>------------------------------
>
>Message: 5
>Date: Tue, 20 Mar 2007 13:12:20 -0000
>From: "Dave Holmes" <dave at neteffekt.co.uk>
>Subject: RE: [Phpwm] Cleaning up addresses
>To: "'West Midlands PHP User Group'" <phpwm at mailman.lug.org.uk>
>Message-ID: <048a01c76af1$65613340$302399c0$@co.uk>
>Content-Type: text/plain;	charset="iso-8859-1"
>
>Free for non commercial use, commercial use requires an enterprise licence
>agreement with the appropriate licensing fees which need to be in place
>otherwise you are putting yourself and your client in the firing line
>
>-----Original Message-----
>From: phpwm-bounces at mailman.lug.org.uk
>[mailto:phpwm-bounces at mailman.lug.org.uk] On Behalf Of Mike Tipping
>Sent: 20 March 2007 12:56
>To: 'West Midlands PHP User Group'
>Subject: RE: [Phpwm] Cleaning up addresses
>
>Google maps API now allows you to geo code UK addresses to Lat longs so
>there is no need to use a licensed file - unless you need the resilience of
>not using something that will be in beta for ever more.
>
>Cheers
>
>Mike
>
>-----Original Message-----
>From: phpwm-bounces at mailman.lug.org.uk
>[mailto:phpwm-bounces at mailman.lug.org.uk] On Behalf Of Dave Holmes
>Sent: 20 March 2007 12:31
>To: 'West Midlands PHP User Group'
>Subject: RE: [Phpwm] Cleaning up addresses
>
>You can get the file from a company call kings wood map mechanics and the
>file is called the code point file.
>
>Server spike is negligible as MySQL eats the maths and in real terms there
>are not that many recs. We are doing a lot more heavy duty processing on 
>the
>satellite tracking software we have created which handles loads of
>concurrent connections from devices communicating via Data calls, SMS and
>GPRS. No performance worries yet. Then again it is running across 6 servers
>all of which are dual xeons with bags of ram.
>
>
>-----Original Message-----
>From: phpwm-bounces at mailman.lug.org.uk
>[mailto:phpwm-bounces at mailman.lug.org.uk] On Behalf Of Phil Beynon
>Sent: 20 March 2007 12:16
>To: West Midlands PHP User Group
>Subject: RE: [Phpwm] Cleaning up addresses
>
>Hi Dave,
>
> > I thought so Phil, my original assumption is correct this can be 
>achieved
> > very easily as I have implemented just this functionality in a number of
> > sites, one of which is now maintained by Darren @ siftware. Basically 
>they
> > have a trader register which allows the user to enter their postcode and
> > search for a builder for example.
> >
> > The system them runs a query on the database to generate a list of 
>traders
> > showing the closest first with an approximate distance, all of
> > this was done
> > by the trader simply entering their postcode when they register. i.e. 
>the
> > whole thing works based on postcode proximity.
>
>Thats another way of doing it I agree, though there are a few situations
>where mine is going to definitely work better.
>
> > To achieve this you need a file which can be licensed for £500 at
> > a reseller
> > rates
>
>Where from?
>
> > then you just need a source postcode and postcode of the traders in
> > the MySQL snip below table d is the search origin postcode and the table 
>e
> > is a company or your example traders postcode, results can be filtered 
>to
> > the most appropriate by ordering on distance and then using the limit
> > statement.
>
>Sure, I can see thats cheaper and less labour intensive than the way we did
>it. :-)
>We relied on multimap for distances / directions.
>
> > <MySQL>
> >
> > (acos(sin(radians(d.latitude)) * sin(radians(e.latitude)) +
> > cos(radians(d.latitude)) * cos(radians(e.latitude)) *
> > cos(radians(d.longitude) - radians(e.longitude)))) * 3437.7387 *
> > 1.150779 as
> > mileage
> >
> > </MySQL>
> >
> > Took around a day to get the search working right and this is something 
>I
> > have used time and time again to provide proximity stuff for my clients.
> >
> > More importantly the results are generated in milliseconds using a 
>single
> > query
>
>This was one query per postcode expansion, since you have to individually
>run the math on all your table entries to get the distances I'm not sure in
>a big database which would be faster, yours would certainly give the server
>a bigger memory spike which on a busy site could be noticeable.
>
>If I was doing it your way I think I would want to pre-generate a postcode
>exclusion table based on exceeding a certain distance.
>
>Phil
>
>
>_______________________________________________
>Phpwm mailing list
>Phpwm at mailman.lug.org.uk
>https://mailman.lug.org.uk/mailman/listinfo/phpwm
>
>
>_______________________________________________
>Phpwm mailing list
>Phpwm at mailman.lug.org.uk
>https://mailman.lug.org.uk/mailman/listinfo/phpwm
>
>
>
>_______________________________________________
>Phpwm mailing list
>Phpwm at mailman.lug.org.uk
>https://mailman.lug.org.uk/mailman/listinfo/phpwm
>
>
>
>
>------------------------------
>
>_______________________________________________
>Phpwm mailing list
>Phpwm at mailman.lug.org.uk
>https://mailman.lug.org.uk/mailman/listinfo/phpwm
>
>
>End of Phpwm Digest, Vol 58, Issue 5
>************************************

_________________________________________________________________
Txt a lot? Get Messenger FREE on your mobile. 
https://livemessenger.mobile.uk.msn.com/