Change Keyboard Maestro to refer to all apps via “match by bundle ID”?

I setup an APFS Volume for Catalina on my MacBook Air which is shared with my Mojave install.

I wanted to try to save some disk space by not downloading the same apps on both Volumes, so I linked the /Applications/ folder from my Mojave install to ~/Applications/ on my Catalina install.

This has broken all of my app-specific settings in Keyboard Maestro, because it has been using “Match by Path” and now it thinks the paths have changed.

I can fix this by switching to “Match by Bundle ID”:

but it’s going to be tedious to do this for every one of my Keyboard Maestro folders and macros which are using paths instead of bundle IDs.

Is there a way to automate this?

@peternlewis - is there a way to do this? Or a way to tell Keyboard Maestro to always use Bundle ID instead of Path [if not for existing ones, then maybe at least for any new ones that I might create in the future] ?

No, and no.

No supported ways anyway, maybe you could hack the plist, but I don't know of any way to do it.

Well, poo.

I guess I’m doing it manually.

Please consider this a request for a feature to use “Match by Bundle ID” as the default.

At least make yourself a macro to script the GUI and make those changes less RSI inducing :smiley:

I’m probably going to edit the kmsync file to fix the paths, since I’m not likely to use it in Catalina often… and then I’ll just install the apps in Catalina in the normal place instead of my previous idea of linking them from the Mojave partition.

Best laid plans, and all that.

I would caution against doing that, unless you determine there is no other way.
The sync file is NOT designed to be edited.
If you want to do a global find/replace, then you could edit the KM Macros master plist file:
~/Library/Application Support/Keyboard Maestro/Keyboard Maestro Macros.plist

Of course, I'm sure you know to do the following BEFORE you make the edits:

  1. Stop KM app and KM Engine
  2. Make a backup of the above plist file

Good luck, and let us know how it goes.

It went fine. I should say that I don't recommend people doing this as I don't know what other potential problems there might be. I have a Keyboard Maestro macro which backs up my kmsync file every time the Keyboard Maestro editor quits, plus Time Machine and a clone that I make with Carbon Copy Cloner, so I knew I could roll things back if needed.

I edited the kmsync file rater than the macros plist because that's what had the errant paths in it.

Like most things, I ended up writing a temporary shell script to do it.

#!/usr/bin/env zsh -f

if [ -e "$HOME/.path" ]
then
	source "$HOME/.path"
else
	PATH="$HOME/scripts:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin"
fi

	# This is the file that needs to be changed
FILE="$HOME/.config/keyboardmaestro/TJs-Macros.kmsync"

	# this gets me to the directory where $FILE exists
cd "$FILE:h"

	# before we do anything, make a backup
cp -vn "$FILE" "$FILE.backup"

	# quit the engine, if running
osascript -e 'tell application "Keyboard Maestro Engine" to quit'

	# quit the app, if running
osascript -e 'tell application "Keyboard Maestro" to quit'

	# give them time to quit
sleep 5

	# prevent the Keyboard Maestro app from launching
chmod 0 '/Applications/Keyboard Maestro.app'

	# convert the kmsync file from a 'binary' plist to an XML plist
plutil -convert xml1 "$FILE"

	# The problematic lines had '/Volumes/SSD/Applications' instead of '/Applications'
	# so this will edit out the '/Volumes/SSD' part and save it to '$FILE.new'
sed 's#/Volumes/SSD/Applications#/Applications#g' "$FILE" > "$FILE.new"

	# rename the original file to end with .old
mv -vn "$FILE" "$FILE.old"

	# rename the new file to have the original filename
mv -vn "$FILE.new" "$FILE"

	# convert the new file back into the 'binary' format from XML
plutil -convert binary1 "$FILE"

	# let the Keyboard Maestro app launch again
chmod 755 '/Applications/Keyboard Maestro.app'

	# re-launch the Keyboard Maestro engine
open -a "Keyboard Maestro engine"

	# re-launch the Keyboard Maestro app
open -a "Keyboard Maestro"

exit 0

Technically this left me with two backups: one that ended with .backup and one that ended with .old but I don't mind having an extra.

Why write a script rather then just doing it by hand?

Speed. It's much faster to run the sed command than to look for all the instances of /Volumes/SSD/Applications and replace them with /Applications

“But didn’t it take you longer to write the script that just do it by hand?”

Yes, but that brings me to the second benefit:

Safety. By thinking through the steps that I wanted to take and scripting them, it gave me a chance to think about "the right way" to do it.

It also gave me a clear list of what was done, and in what order, so that if something did go wrong, I could go restore the backup file and try again by editing the script to do things differently where I thought changes were needed, but still doing all the “right” steps in all the “right” order.

Again, I don’t recommend this, but if someone decided that they had to, for some reason, make mass adjustments to their .kmsync folder, this is how I would recommend they try it, especially because it starts with making a backup of the file.

FWIW - it seems to have worked fine. But I’ll keep the backups around for a few days, just to be sure.

Now that you mention ~/Library/Application Support/Keyboard Maestro/Keyboard Maestro Macros.plist it occurs to me that I should probably run the same process on it, too, Which I can now do by editing one line in that shell script above. And I’ve already thought of some ways that I can improve the script, so, that’s a plus.

If the errant paths are in the kmsync file, they should also be in the Macros.plist file.
In fact, my understanding is that the kmsync file is created from the Macros.plist file.
Perhaps @peternlewis can confirm.

The two files should be identical. The kmsync file is written as a copy of the data written to the plist, and vice versa.

Ah, thank you and @JMichaelTX for helping me understand the relationship between those two files better. Obviously the plist was the one I should have focused on. I’ve learned my new thing for the day :slight_smile:

1 Like