KM Modifying Script File

I created an apple script (.scpt file) and I use it in a KM Macro.
I have that applescript in a cloud folder to sync.
The Macro is used for time stamping videos.
Every time I press the Keyboard shortcut to run the Macro,
I get a cloud sync popup that says the script.scpt has been modified.
I check the file and indeed the modified date is the current time.
Why does KM cause the .scpt file to update it’s modified date?
This creates a problem on cloud sync since I save versions in case of accidental changes to files.

Is this an expected behavior?
If so, does this mean I can’t use a cloud sync folder for my applescripts used in KM?


A scpt script file contains the text source of the script and also the compiled code. I don’t know the technical details why the script is changed each time, but it happens every time you execute the script via osascript. KM also runs the scripts via osascript, so the behavior is not limited to KM.

If this is a problem try one of these:

Save as text script

Save the script as text (with the .applescript extension) and run it as usual with the Execute AppleScript action:


Decompile and execute

Leave your script as it is (.scpt) and run it in the shell with

osadecompile <myScript.scpt> | osascript

You can do this in a Execute Shell Script KM action:


This will not work with all scripts, for example the changed values of properties are no longer stored this way. So, double-check if your scripts are working as they should.

1 Like

As a footnote to Tom’s help, one of the things that happens, with AppleScript at least, is that the runtime state of any property values is stored in the .scpt file, and can be reused at the next run.

(It means that you can write scripts which retain and use a memory of something in the previous run)

1 Like

Adding one more option: At the start of your macro, you could copy the script file to a local folder, and run it from there. Then it wouldn’t matter if it changed, because you wouldn’t sync it back to the cloud.


Thanks for the ideas.
Currently I only run the scripts using KM so I decided to cut and paste the Script into KM directly.
That seems to be working as expected.
It’s not very complex, just captures the filename and current time in VLC and writes the info to a file.
I can later run a script to create a batch process to extract clips from videos.
This has made it much faster to go through the 100’s of home videos to trim them down.


1 Like

I learned some new things:

I had four test scripts, all compiled files (.scpt):

  • noVar.scpt: contains no variables
  • localVar.scpt: contains a variable that is set in a handler
  • globalVar.scpt: contains a variable that is set in the run handler (top level handler)
  • property.scpt: contains a property that gets changed on the first run

I have executed the scripts with

  • osascript (Terminal)
  • FastScripts


The noVar.scpt never changes, not with osascript, nor with FastScripts. This was expected.

localVar.scpt behaves exactly as noVar.scpt

globalVar.scpt executed with osascript:

  • 1st run: md5 checksum changed and modification time changed
  • 2nd run: checksum unchanged, but modification time changed
  • 3rd run: checksum unchanged, but modification time changed again

So, it seems, on the 2nd and 3rd run the file is temporarily changed but then reverted back. (?)

globalVar.scpt executed with FastScripts:

  • 1st run: checksum and modification time unchanged
  • 2nd run: ditto
  • 3rd run: ditto

property.scpt behaves exactly like globalVar.scpt.

Now I’m wondering:

  • Why do globalVar.scpt and property.scpt behave identically? I understand that property.scpt changes because of the changed value of the property. But why does globalVar.scpt also change (with osascript)?

  • Why does property.scpt not change when executed with FastScripts? Where is the changed property value stored?
    (Extended attributes, including resource fork, are also unchanged.)

Any insight?

Not sure - global vars do show a degree of persistence (between runs, but not between sessions), so state may be written out to file for them as well.

This, for example returns an incremented value each time it is run in a given session, though its value reverts between sessions:

global gExpression

on succ()
    on error
        set gExpression to 0
    end try
    gExpression + 1
end succ

set gExpression to succ()

I wonder whether FastScripts is running is running from its own (text/compiled) copy/cache, rather than the user supplied script file ?

Yes, makes sense. Behaves like a script with a property.

I’ve found a database at ~/Library/Caches/ but not modified recently.

BTW, scripts executed via LaunchBar behave like the ones from FastScripts.

FastScripts seems to store the script state in memory. When I quit and relaunch it the state is gone (changed properties or the global variable in your example script).

I’ve said, LaunchBar behaves like FastScripts. This is true in the sense that it doesn’t modify the scpt file. But I noticed only now that it doesn’t remember the script state at all.(!)

Hey Tom,

That’s correct. FastScripts stopped rewriting the actual script file years ago.


Yes, but I didn’t expect that it keeps the script state only in memory. I expected to find it written to some disk cache somewhere, at least when it quits.

Hey Tom,

I can’t remember anymore what Daniel’s rational for not writing the file was. It’s been complained about.

Property saving is in-memory-only as far as I know. I’m pretty sure FastScripts doesn’t cache to disk at all, and it goes away as soon as you quit FastScripts.

You can buzz Daniel about it if you want. He’s good about responding.


I prefer to not disturb him while the progress indicator is still in his todo queue :wink:

Hey Tom,


Personally I think it’s a good idea to bug him about FastScripts. He needs to be reminded that it’s a loved utility out in Mac-land.

(He doesn’t make much money off of it.)


Good point. But I also already mailed him about the text vs rich text thingy.

The quintessence of his answer was “I’ll see what I can do.” … and for the progress bar: “yeah, that is also something I’d like to add support for. I have some catching up to do!”

So, there is a chance that he’s already bugged enough by me :roll_eyes:

But probably I’ll follow your advice – but only to remind him that it’s a loved utility :slightly_smiling_face: