Please Help.
I’m sure this is simple,how do I schedule scripts,I don’t want to use any 3rd party software.
Is there an “If” function I can use to check the date and time,If so how do i use it.
Thanks.
If you save a script as a stay open application, you can use an idle
handler. For instance:
property beginTime : date "Monday, April 8, 2002 9:00:00 AM"
property endTime : date "Monday, April 8, 2002 5:00:00 PM"
on idle
set currDate to (current date)
-- Check to see if the current date and time is between beginTime and endTime.
if currDate is greater than beginTime and currDate is less than endTime then
display dialog "What would you like me to do?"
else -- If not within the target times...
set beginTime to beginTime + (24 * hours) -- set it up for the next day
set endTime to beginTime + (24 * hours) -- set it up for the next day
end if
return (1 * days) -- check again in 1 day - it could be expressed in seconds as (60 * 60 * 24)
end idle
This is just sample code to get you started and show what’s possible.
Dates and times can be tough in AppleScript, particularly to beginners, so
you may need to play with it to tailor it to your needs.
I’ve only had one cup of coffee after less than enough sleep, so hopefully I
haven’t committed any serious blunders.
Rob J
You don’t say which OS you’re using. OSX comes with the usual Unix scheduling tools (which I haven’t used yet), and should support the launching of scripts: Perl. Applescript, whatever. If you’re using OS9 or earlier, even if you don’t want to us 3rd party software, you may already have it installed on your machines (e.g., iDo).
Depending on whether you wish to know the time the computer has idled, or whether you wish to schedule a script at times of day or following certain events or repeatedly try:
Acron http://wrcu.coLgate.edu/sean/Acron/index.html
Akua Sweets http://osaxen.com/index.php3?id=akua_sweets
Cron http://gargravarr.cc.utexas.edu/cron/index.html
Cruise Control http://www.walnutsys.com/
DaemonCron Lite 1.5 http://homepage.mac.com/dcoshel/daemon.html
idle time osax http://osaxen.com/index.php3?id=idle_time
idle time extension http://www.dijas.com/ely-old/files-scripting.html
iDo Script Scheduler http://www.sophisticated.com/software/
Keyquencer http://www.binarysoft.com/kqmac/kqmac.html
MacAT http://gimr.garvan.unsw.edu.au/gerham/macsos/macat/index.html
PowerTask http://www.compsoftspec.com/powertask.html
QuicKeys http://www.quickeys.com/
Scheduler http://hotyellow98.com/jvarela/
Script Scheduler http://www.wmotion.com/products.html
Script Timer http://www.theboss.net/appsmore/
Sleep Commands http://home.earthlink.net/~eagrant/
T-Minus Ten http://home.austin.rr.com/mk/tmt/tmt.html
You may already own iDo, as it came free with OS8 thru 8.6, I think.
I guess Rob got the solution, but there is one thing I can add: Idle loops aren’t very predictable; their execution is never determined (depends on speed and other use of the machine). My experience is that sometimes they hardly respond after some time.
Another idea would be to use Rob’s routines in a repeat loop (and do not save your applet as stay-open) instead of an idle loop:
repeat
delay 30 minutes -- or other value, determines time lag
--Rob's routine (except his return value)
end repeat
This way, your applet will give itself a higher priority.
Eelco Houwink
Eelco, I can agree with you to a very slight extent in that you can’t rely on the return value of an idle handler being spot on. As you suggest it depends what else is making demands on the CPU. Hovever, when you say: “My experience is that sometimes they hardly respond after some time” I lose you completely. Forgive me, but that is most likely due to a peculiarity of your script - or the circumstances under which you expect the idle handler to work - relying on one while you are doing intensive work in Photoshop would be unwise! Apart from the caveat that “return 3” might take 4, idle handlers correctly implemented are fantastically reliable.
As for using either a “repeat loop” or a “delay” I cannot think of anything worse than either - other than for a demonstation of what happens when you really clog up the CPU in a big way! If (obviously not in X) you opted for “pause for” that would be a tiny bit more sensible, but I doubt not that most experienced scripters would opt for an idle handler whenever possible - and certainly for the task required here. A repeat loop spinning and spinning and spinning - never, Eelco, never. A “delay” waiting for ages to terminate? Also never, Eelco - never, never, never.
Rob’s method - in spite of inadequate coffee input - is beyond doubt the way to go.
Andreas
Having said all that (and I wouldn’t change a word), and in spite of what the questioner said, I wouldn’t hesitate myself to call up the perfect tool for the job - QuicKeys. Why the objection? Why have YA app running when QK is already there? (If not why not?) The routine itself in a script for sure (either within QK or independent), but called up by QK - totally transparent - two seconds work - totally reliable.
Be idle my friends
Andreas
Eelco, your reply is perfectly sensible, but I still disagree. Rather than your N¼ 3 being an “aging effect” I wonder if perhaps you are allowing the RAM requirement of your app(s) to keep growing. Should you perhaps, for instance, be periodically emptying some variables? When an app shows that behaviour have you checked its size in the Finder compared to its size just after compiling?
Andreas
Andreas,
Although I agree with most of what you said in principle, our practical scripting experiences remain different. On the subject of idle handler vs. repeat&delay I have been testing quite a few moderately to complex scripts (50…300 lines of code), and changed most idle-handlers by repeat loops. I keep having bad experiences with idle handlers including:
- Unpredictable triggering – we seem to agee on that.
- Unexplainable time lags (to complete halts) with calls to the core OS (such as reading or writing text files), to the Finder or to OSAX-en, when loading other scripts etc. etc.
- More than accidental increase of these effects after multiple executions of the same idle handler (“aging effect”)
These deficiencies can be observed and be replicated on my machine by adding a routine that speak out the ticks or the current date. OK, it may be the side-effect of a huge number of extensions and folklorism I have in my OS9 setup, but I can’t change that for a number of reasons.
As I said earlier, using repeat loops in combination with a delay (pause for, sleep etc, I am not aware which are the least processing intensive) resolved this. You are probably right that this goes at the expense of clogging the CPU – however, in my setups (my own G3 Pismo and customers G4’s and double G4 machines) this hasn’t been a problem. I can’t test with Photoshop as I do not have it. I have done tests with my kids (yes, critical testers) who are running CPU-intensive games like 4*4 Evolution on a 450 Mhz iMac while these applets are running in the background…which says something to me.
To conclude: you will be certainly right in your assessments in theory, but from a practical point of view I will keep using repeat loops…
As I would never say “never” in these cases, I would certainly be interested to do some additional testing on the matter. Indeed, OSX is completely off-topic here (as I haven’t climbed the hill of migrating any scripts yet)
Eelco Houwink
Andreas ,
That makes sense - if it wasn’t that the “aging resonse” effect also appeared when executing minimalist idle scripts (like just a speak command or writing a textfile) in OS9.
I also have been thinking about it - it could be that other apps showed growing RAM demands, as well as daily work would result in RAM fragmentation and/or issues with OS9 scratch/cache disk etc.
But then, other apps then would also have showed performance degradation which wasn’t the case or wasn’t noticeable.
In OSX today I repeated the experiment and indeed, idle sequences now appear (as predictable) to be at regular intervals. (less expected is that I DO have to restart OSX because of performance degradation / severe disk swapping after some intensive use, at least twice a day on a 640 Mb machine, but that’s another subject)
So I can only conclude it has to do with my OS9 setup. What I remember is that long ago, I investigated the amount of CPU time eated by different processes (with a 1996 utility called “Monitor”, or was it “TimeSlice” ??) and found that only the Finder eated a LOT of slices - also in background. Unfortuantely, I haven’t or couldn’t log it.
And I haven’t seen a better tool for the purpose since…
On the subject of “growing RAM demand over time”: do you think that Apple’s AS implementation’s (1.6 … 1.8.2 alpha) are clean…?
Eelco Houwink
Eelco, I have to bow out here because I’m still with AS 1.3.7 in OS 8.6. But I’m still going to remain my usual pig-headed self - I just can’t, cannot, won’t believe that having an app churning away in a repeat loop in the background - or waiting for a lengthy delay - can be good ideas. However, I have to admit that there could be complications of later versions of OS or AS than mine of which I am ignorant.
How about a view from one of our respected site elders/betters/gurus? Don’t be shy - do reply.
Hi. I write this little script. we need it to capture the news from a TV-Channel every day on same time. the “dates” in the set-lines are not necassary. I hope it helps. Markus
repeat
set starttime to date "Montag, 15. April 2002 21:17:00 Uhr"
set endtime to date "Montag, 15. April 2002 21:18:00 Uhr"
set myTime to current date
if the time string of starttime is the time string of myTime then
tell application "ProTV 2.6.3"
activate
end tell
end if
if the time string of endtime is the time string of myTime then
tell application "ProTV 2.6.3"
quit
end tell
end if end repeat
I’m not sure, Markus, whether I should thank you for that or not. (Just joking!)
Eelco - OK, so someone else would also do it in that second-rate!! way. I would do it in a much better way.
Am I being pig-headed or am I being - pig-headed?
Andreas
Vive la difference!
Quelle difference? It’s that whereas you guys keep repeating yourselves I just prefer to be idle.