While there are a number of ways to tell how long a Script takes to run in real time, the results are dependent on the capabilities of the Mac running it. These results obviously don’t scale from one model to another. Is there a way to evaluate a script in terms of the number of machine cycles it takes to run or some similar scalable measure? If there were such a way, a true estimate of the time remaining to perform a task could be shown in any of several ways.
Emmanuel posted recently a script for gigacycles… Hmmm… Here is it (requires Smile):
http://lists.apple.com/archives/applescript-users/2005/Nov/msg00150.html
I’ll repeat something I’ve mentioned before:
Now, I’m not certain how you would implement this in a specific script, but it’s something to think about.
The Daring Fireball link gives this as a clue:
set bootSeconds to (do shell script "cat /var/db/loginwindow.boottime") as number
The loginwindow.boottime variable is how long the system takes to boot - the time the progress bar runs when you boot up your system. That’s got to be a reasonable indicator of how fast the machine is.
If you want to see the bootup window and progress bar, run this in the Terminal: /usr/libexec/WaitingForLoginWindow and you’ll see a very slow progress bar because it’s running its default setting.
To stop it, again in the Terminal, type: killall WaitingForLoginWindow
A further thought here: If you time a process on your machine and then scale that time with respect to bootSeconds above, it ought to scale to other machines. I’ve got a new dual-core G5 sitting on the floor - when I get it set up, I’ll try it.
This could be good for something that doesn’t give feedback, such as a long shell script.
Exactly my thought, but there’s a problem when you think how to do it — you’d have to run a separate process to advance the progress bar because your script would be frozen while waiting for a response from the shell script.
Sure, right after I learn how to do that. I’ve never written an osascript or used iHook. Useful thing to learn, however, so I’ll add it to the many things I have to learn (soon after I partition the HD on my new G5 and get it up and running again with all my stuff transferred over - not trivial when one of the machines doesn’t understand target mode and the wrong one does.
I suppose the scheme would go something like this:
Set up an osascript that would do the required time scaling from LoginWindowBootTime from a passed in value of total time, start up Progress Bar with 20 increments and the appropriate timing loop to increment it 20 times and put up meaningful text along the way, and then quit Progress Bar and terminate.
Set up your “main” script to do whatever long operation was required, knowing how long it took on average (I use the GetMilliSec.osax to do that, running the process several times and averaging the result). Have this script start the osascript first and then the process that needed a progress bar (which would run as a separate thread and look after the PBar).
Might even work 
GetMilliSec could eliminate the requirements for Smile’s chrono 
FWIW, I have one script that looks something like this:
-- more stuff up here
tell ProgressBar
barberPole(bool)
setStatusTop to "Preparing to [whatever]."
end tell
-- do a few small things
tell ProgressBar
barberPole(false)
setMax to (fileCount * 3)
end tell
repeat with thisItem in fileList
tell ProgressBar to setStatusTop to "Processing: " & thisItem
-- do first step
tell ProgressBar to increase by 1
-- do second step
tell ProgressBar to increase by 1
-- do third step
tell ProgressBar to increase by 1
end repeat
-- also stuff down here