macOS-Einstellungen lesen und schreiben: defaults, plutil und warum cfprefsd direkte Dateiänderungen verdeckt

Worum es geht

defaults liest und schreibt Werte innerhalb einer Einstellungsdomäne – normalerweise eine Property List unter ~/Library/Preferences/<domain>.plist oder /Library/Preferences/<domain>.plist – über einen Schlüsselpfad. XML- oder Binär-plist-Syntax muss dafür nicht geparst werden: defaults read com.apple.dock, defaults write com.apple.dock autohide -bool true, defaults delete com.apple.dock autohide. plutil -convert xml1 -o - file.plist konvertiert zwischen der binären, der XML- und der JSON-Kodierung von plist-Dateien, und plutil -lint file.plist meldet, ob sich eine Datei überhaupt parsen lässt, bevor man ihr vertraut oder sie ausliefert. /usr/libexec/PlistBuddy -c "Print :SomeKey" file.plist liest oder ändert einen einzelnen Eintrag in einer beliebigen plist, ganz ohne das Domänenmodell von defaults.

Warum es wichtig ist

macOS liest eine Einstellungsdatei nicht direkt in dem Moment, in dem eine App eine Einstellung abfragt. Ein Daemon pro Benutzer, cfprefsd, hält die Einstellungswerte im Arbeitsspeicher im Cache und vermittelt jeden Lese- und Schreibzugriff über die CoreFoundation-Preferences-API, die sowohl defaults als auch die meisten Apps verwenden. Wird eine plist-Datei auf der Festplatte mit einem Texteditor, mit cp oder durch eine wiederhergestellte Sicherung überschrieben oder ersetzt, wird dieser Cache nicht invalidiert: Eine laufende App behält den Wert, den cfprefsd ihr zuletzt geliefert hat. Die Änderung scheint daher wirkungslos, bis die App neu gestartet oder die gecachte Domäne neu geladen wird.

So wird es angewendet

• defaults write/delete der manuellen Bearbeitung der plist-Datei vorziehen; der Weg über dieselbe API, die cfprefsd vermittelt, vermeidet für diese Änderung das Problem des veralteten Caches.
• Muss eine Datei direkt bearbeitet werden (Massenmigration, Wiederherstellung aus einer Sicherung), zuerst die zugehörige App beenden oder anschliessend killall cfprefsd ausführen, um ein Neuladen von der Festplatte zu erzwingen. Das betrifft auch die gecachten Einstellungen anderer Prozesse, daher möglichst dann ausführen, wenn sonst wenig läuft.
• Jede plist, die ausgeliefert oder wiederhergestellt werden soll, vorher mit plutil -lint prüfen; eine beschädigte Datei führt bei manchen Apps stillschweigend zu den Standardwerten, bei anderen zu einem harten Fehler.
• Für einen schnellen, lesbaren Auszug plutil -p file.plist verwenden, wenn nur inspiziert und nicht bearbeitet wird.

Stolpersteine

• Zwei plist-Dateien vergleichen (Diff) und daraus das Verhalten der laufenden App ableiten; die App liefert möglicherweise weiterhin einen alten, gecachten Wert aus.
• Mit defaults schreiben, während die Ziel-App läuft, und erwarten, dass sie die Änderung ohne Neustart bemerkt; manche Apps abonnieren Änderungsbenachrichtigungen, die meisten nicht.
• Vergessen, dass binäre plist-Dateien kein Text sind: cat, sed oder grep direkt darauf zeigen nur unlesbaren Zeichensalat; zuerst immer plutil -convert oder -p verwenden.