Feature Request: Enhancements to Execute Script

@peternlewis, I'd like to request some enhancements to the "Execute Script" Action:

  1. Add a "with Parameter" option, like in "Execute Macro"
  • This would be huge IMO
  • It would allow us to have general purpose scripts, where the data acted on does not require a separate "Set Variable" action
  1. Add a "Abort on Error" option
  • @DanThomas and I have been collaborating on a best practice for error handling, but having a built-in option would be very helplful, and make it more reliable for all users
  • IMO, the default value should be true (abort if there is an error). That would be the safest.
  • I know the norm is to use the Mac Notification system, but displaying a popup with the error message that requires the user to close would be best, IMO.

These enhancements do NOT have to be done at the same time.

For reference for all, here's the current Execute Script options:


1 Like

+1 on “with parameter.” I don’t have an issue with error handling, although I can see the benefit, but not having to create and pass along and delete variables just to pass a string into a script would be super handy.


Given how much flack I got when I added abort on error to the Search Variable/Clipboard, turning this on by default for existing macros would undoubtedly be problematic.

I'm not sure how "with parameter" would work for text shell scripts. AppleScript has a method of receiving parameters. Not sure about JXA. So its not entirely clear cut how to do this.

It's also not clear what constitutes an error in a script.

So I will look in to it, but its not entirely certain that there is enough good answers to result in an implementation.

Anything that throws an error in AppleScript or JXA, that would be caught by the "try/catch" block (if there was one).

If the script does not automatically return some type of error code to KM, then I can see how that would be problematic. If you can't get a clear signal from the script when an error occurs, then it's not worth messing with the KM Action.

Both @DanThomas and I have developed similar error handling methods that work well.

  • Dan's method relies on the script always returning "OK" if there were no errors
  • My method relies on the script returning a string that starts with "[ERROR]" if there was an error. Otherwise, the script was a success.
  • Both methods require the script to use a try/catch block around the entire script to catch all errors.

So, maybe that is good enough. Other users can choose between those two methods, or devise their own, or use none at all.