förra veckan har macadmin Kyle Crawford upptäckt att på macOS High Sierra kommer defaults
att ta bort en egenskapslistfil med ogiltig PLIST/XML-syntax, även när du bara försöker läsa data. Erik Holtham har en mer detaljerad OpenRadar bugg.
Patrik Wardle har hittat den relevanta koden, som raderar filen när den inte valideras.
detta är dåligt. Tack till alla inblandade för att hitta, dokumentera och dela detta.
detta är nytt beteende i High Sierra. Jag är ännu inte säker på vilken version av High Sierra detta nya beteende introducerades. Beteendet är meningsfullt i samband med ett program som försöker läsa en inställningsfil, men verktyget defaults
som tar bort godtyckliga filer är naturligtvis farligt.
Uppdatering: detta beteende har rättats i 10.13.4. Det är dock fortfarande bra att undvika
defaults
för något annat än faktiska preferensfiler.
Vad ska man göra?
som vanligt, var inte panik. Detta påverkar bara Mac-datorer som kör High Sierra och korrupta eller trasiga filer. Men om du har ett skript som oavsiktligt pekar kommandot defaults
på en annan fil, kommer det att radera det. Så du måste använda den med försiktighet.
det är förmodligen en bra praxis att verifiera en fil innan du försöker ändra den med kommandot defaults
i ett skript med kommandot plutil
:
if ! plutil -lint path/to/file.plist; then echo "broken plist" exit 1else defaults path/to/file …fi
alternativ till standardvärden
Alternativt kan och bör du använda plutil
eller PlistBuddy
för att läsa och ändra egenskapslistfiler.
Läs mer om
plutil
,PlistBuddy
och andra verktyg för att läsa och skriva fastighetslistor i min bok: ”Fastighetslistor, Inställningar och profiler för Apple-administratörer”
plutil
är tyvärr inte riktigt bra att läsa ett enda värde från en egenskapslista fil. Verbet extract
visar vilket värde som helst som sin egen plist. Kommandot plutil
är användbart för att redigera befintliga plist-filer. (Läs detaljer om kommandot plutil
.)
PlistBuddy
, men är mycket användbart för både läsa en skrivvärden till en egenskap listfil:
$ /usr/libexec/PlistBuddy berry.plist -c "print size"$ /usr/libexec/PlistBuddy berry.plist -c "set size enormous"
PlistBuddy
har den ytterligare fördelen att tillåta att lägga till eller redigera värden kapslade djupt i dict
eller array
strukturer.
du kan få mer information om PlistBuddy
i sin man sida eller min bok.
det interaktiva läget för PlistBuddy
är också mycket användbart.
så standardkommandot är dött?
Nej.
Apple har varnat oss för att inte använda defaults
för generic property list-filredigering och parsning ganska länge på defaults
– kommandos man-sida:
varning: standardkommandot kommer att ändras i en kommande större utgåva för att endast fungera på preferensdomäner. Allmänna plist manipulation verktyg kommer att vikas in i ett annat kommandoradsprogram.
som denna Varning anger, läser och skriver verktyget defaults
data till plist-filer via macOS: s preferenssystem. Detta har fördelen att verktyget får (och ändrar) det aktuella värdet oavsett om det är Cachat i minnet eller inte. När en applikation lyssnar på meddelanden om att en preferens har ändrats (inte många gör) kommer den att meddelas.
filer för preferensdomäner lagras vanligtvis i /Library/Preferences/
, ~/Library/Preferences
eller deras ByHost
undermappar. Sandboxade applikationer kommer att ha sina preferensfiler i sin behållare.
det finns dock många andra filer som är egenskapslistfiler som inte ingår i användarstandardsystemet: launchd
filer, konfigurationsprofiler och AutoPkg-recept för att bara nämna några.
Mac-administratörer använder vanligtvis verktyget defaults
, trots Apples varning, för att skapa, läsa och redigera generiska plist-filer. Som nämnts ovan är plutil
, PlistBuddy
eller direkt manipulation genom Obj-C, Python eller Swift bättre val för generiska plist-filer.