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.
