AppleScript: Execute command when timestamp on file changes?

Due to to a tcl/tk issue, I’ll have to drop that aspect of things for the moment.

However, I can use the following well, but would like to be able to gracefully exit this when I’m through using it.


-- extend the default 2 minute timeout
with timeout of (30 * 60) seconds
	
	-- set path relative to home folder
	set default_folder_Location to (path to home folder as text) & "01 Translations:03 Projects:"
	set htmlFile to (choose file with prompt "File to convert:" default location alias default_folder_Location)
	set htmlFilePOSIX to the quoted form of POSIX path of htmlFile
	set previewTCL to (path to home folder as text) & "Library:Preferences:OmegaT:script:preview.tcl"
	set previewTCLPOSIX to the quoted form of POSIX path of previewTCL
	
	tell application "Finder"
		reveal htmlFile
		do shell script "textutil -convert html " & htmlFilePOSIX
		tell application "System Events"
			tell application "Opera" to activate
		end tell
	end tell
	repeat
		do shell script "textutil -convert html " & htmlFilePOSIX
		delay 10
	end repeat
	
	-- end timeout
end timeout

Is there a way to stop this now without using a forced quit via alt+cmd+esc?

And is it possible to code this so that when the program closes the html file that was created is also deleted?

Thanks,

Bowjest

Just an idea: Doesn’t a hard link work (is something else than an alias)?

Hello.

There is indeed another way to do this. look in the last post here.

The idea is that you make an applet, that you register as a receiver of open url.

You should of course also check that it is a file url, and that it is within the source tree, where you want to check the timestamp, or else bypass the url to opera, in this case.
Then you can use the idlehandler to check for the updates sought for, and finally bypass it to opera, when it is stable.

That should be a technique, not involving launchd, and give a flexible way to poll if files are changed, maintaining a list of files that are currently under inspection.

The first time you handle one of those files by a script, you open it with finder, to make it a member of those files that are under inspection.

The return value of the idle handler, dictates how often it is run, and it should be quite comfortable, to run it say every 3 minutes or such.

Thanks, McUsr,

I’m looking at that now and although I don’t really understand it, I’m hoping with some re-reading and trial and error I can make something of it.

While I’m doing that, can you of Stefan (or anyone else) tell me if the following is likely to use too much system overhead/processing energy:


repeat
		
	set newTimestamp to (do shell script "stat " & htmlFilePOSIX & " | " & "cut -d \" \" -f12")
		
	if newTimestamp is not equal to oldTimestamp then
		do shell script "textutil -convert html " & htmlFilePOSIX
		set newTimestampt to oldTimestamp			
		delay 10
	end if
end repeat

The reason I’m asking is that I don’t really understand how a “listener” would be better than just checking the timestamp every 10 seconds and then doing something if needed (or is this somehow redundant?).

Looking at the system temp and Activity Monitor, things don’t seem to be too hot or using too much resource, so am thinking perhaps this solution would be good enough? Would you both agree?

And, I apologise again for asking, but I think two points have gotten lost in the mix:

  1. Is there a way to get this to gracefully exit without putting in a dialog asking the user to click “quit” or “cancel” (i.e. is there a way to make cmd+q exit this program/script)? So far I’ve only been able to force quit it using alt+cmd+esc.

  2. Is there a way to delete the HTML file that is created using the “do shell script” above when the app exits?

Many thanks,

Bowjest

Hello!

Honestly, I think you will be the first to know, and then you will just increase the delay until you find something usable interval, eventually.

As for a way to exit this:

You could run another script, that generates a text file, you test for in this loop, which will make your loop exit gracefully when found.

Thanks, McUsr, a nice idea.

I think I’ll work with my current two-script solution for now as it’s fairly easy and has no impact on system overhead.

Regards,

Bowjest