A fascinating question, because I too have been wondering about the mysterious new XML-format "plist" files in Mac OS X and how to ascertain if any of them are messed up without having the associated application start spitting up bits.
It turns out that there's a great little command-line application accessible within Terminal (Applications -> Utilities -> Terminal) that performs just what you seek, a plist verification program called plutil.
At it's most basic you can just hand it a suspect preferences file and it'll scan it to see if all is well with the overall XML format. The program doesn't know how a given application interprets its preferences, so if a 'true' should be 'false' that won't be flagged, of course.
$ cd ~/Library/Preferences
$ plutil com.microsoft.Word.plist
com.microsoft.Word.plist: OK
$
You can replace the individual plist name with a set of all plist files in the Preferences directory with "*.plist" instead, as in: plutil *.plist. If you try this, however, you'll find that it has a status output line for each file checked which means that you lose the problems in the stream of successes.
To avoid this problem, plutil has another flag, '-s', that specifies you should only be shown errors. Now we're getting somewhere! Here's what happens on my computer when I run this:
$ plutil -s *.plist
IM_Installer.plist:
stream had too few bytes
com.Intego.NetUpdateInstaller.plist:
stream had too few bytes
com.apple.NetInfoManager.plist:
stream had too few bytes
com.apple.mix.plist:
Conversion of data failed. The file is not UTF-8, or in the
encoding specified in XML header if XML.
com.realmacsoftware.buttonbuilder.plist:
XML parser error:
Unexpected character T at line 1
Old-style plist parser error:
Unexpected ';' or '=' after key at line 2
Not too good. Well, actually there are 244 plist files in this directory (use ls *plist | wc -l to figure that out for yourself) so hiccups with four or five probably isn't too bad.
The standard way to fix a corrupted preferences file is to just delete it and then reset any custom settings in that specific application next time it's launched. So I'll do that, but not by typing in the filenames. How terribly... archaic! Instead, I'll use the helpful Mac OS X shell backquote feature to run the test against all the preferences files again, then extract just the filenames:
$ rm -i `plutil -s *.plist | grep 'plist:' | sed 's/://g'`
remove IM_Installer.plist? y
remove com.Intego.NetUpdateInstaller.plist? y
remove com.apple.NetInfoManager.plist? y
remove com.apple.mix.plist? y
remove com.realmacsoftware.buttonbuilder.plist? y
Notice that the inclusion of the '-i' flag to rm causes the program to prompt me before each file is deleted. A nice safety trick!
If you're thinking we're done, you're not quite correct. There's a second directory full of plist files, the system Library at /Library:
$ cd /Library/Preferences
$ sudo plutil -s *.plist
Password:
com.Logitech.ControlCenter.plist:
stream had too few bytes
$
This time you'll want to use the sudo command to make sure that the plutil command can read even those preferences files that are only readable by the administrator. For completeness sake, natch!
If there are any preference files in the results that you want to trash, you'll probably need to use sudo rm rather than just rm.
Phew. Long answer for what seems like a simple question. Hope this is helpful!
Sign up for my weekly AskDaveTaylor Newsletter and you'll receive even more tech and gadget help
right to your inbox, along with exclusive news and industry updates. It's good stuff. I promise!
Dave,
Wow! Great info. Can't wait to try it at work next week. Thanks!