plb<\/a><\/code> the plist broker<\/strong> and plx<\/a><\/code> the plist extractor<\/strong>. The value<\/em> of plb<\/a><\/code><\/code> is its ability to visualize<\/strong> a plist as you will see below, just like my tool jpt<\/a><\/code> does for JSON. plb<\/a><\/code><\/code> can map out the complete paths and values that may be buried within nested dictionaries and arrays. It can help you see the “shape” of a plist and recognize patterns. They are both shell scripts and<\/em> functions you can incorporate into your<\/em> own scripts, like my other embeddable tools: jpt<\/a><\/code>, ljt<\/a><\/code>, jse<\/a><\/code> and shui<\/a><\/code><\/p>\n\n\n\nBecause Reasons, part 1<\/h2>\n\n\n\n
It was while writing Detecting Apple Intelligence and ChatGPT Integration Status<\/a> last November, I decided to make a plist tool that could thoroughly map and navigate plist paths, easily extract plain text values and most importantly, effortlessly navigate into plists stored as base64 encoded data. What I thought was a new trend, is actually not<\/em>: Binary plist data in plists is nothing new<\/em> and if that’s<\/em> the case then, it’s about time we have a tool for work with them! Funnily enough, in the above post I complained with an “ATTN: Craig Federighi” about the obfuscation games I felt Apple engineers were playing with the Apple Intelligence prefs as these inscrutable data blobs. Now, in the upcoming macOS 15.4 release, lo and behold those keys have disappeared<\/em> from .GlobalPreferences<\/code>! \ud83d\udca5 Um, thanks<\/em>, I guess? “I see dead keys” now. \ud83d\ude2c “Be careful what you wish for, it might diminish your tool’s relevance!” as they (kinda<\/em>) say. Still, there’s lots<\/em> of binary plist data embedded in your preferences, when you run the examples for plb<\/a><\/code><\/code> below you’ll see.<\/p>\n\n\n\nBecause Reasons, part 2<\/h2>\n\n\n\n
You might still<\/em> be asking yourself: “Why<\/em> do we need yet another plist tool though? We have defaults<\/code>, PlistBuddy<\/code>, and plutil<\/code>. Why do we need anything else?!”. Well, let me tell you they all have their strengths and weaknesses:<\/p>\n\n\n\n\ndefaults<\/code> can only get the value of a top level key, it does not work with nested paths; it cannot output XML unless it is the entire plist; it converts ISO 8601 dates to local time using abbreviated time zone which are notoriously hard to parse with date<\/code>; empty preferences return an error as if they don’t exist; it cannot take piped input; binary data is output as an abridged hex dump<\/li>\n\n\n\n- With
plutil -extract<\/code> there is no way to extract data from the root of a non-dictionary type plist, a key name is always<\/em> required; key paths are period delimited, so keys with periods in their name require \\\\<\/code> escapes which gets unsightly quickly with when reverse domain style key names are used; the JSON extract method balks at outputting most plist data types (real, boolean, date, data); the -convert xml1<\/code> function makes it too easy to overwrite the source file if you forget to add the awkward -o -<\/code> syntax to send to stdout versus the source file<\/li>\n\n\n\nPlistBuddy<\/code> is a mixed bag: it can work with paths; it has a colon delimited key path notation that’s not flummoxed by periods; colons are more easily escaped with a single vs. double slash; it can output XML with -x<\/code>; however, it cannot process binary plist data; it adds a newline to all output which alters binary output and especially corrupt<\/em>s binary plist data; redirected input requires \/dev\/stdin<\/code> to be specified as the file; piped input does not<\/em> work, only here documents do (awkward looking one-liners ensue)<\/li>\n<\/ul>\n\n\n\nplb in action<\/h2>\n\n\n\nGetting the lay of the land<\/h3>\n\n\n\n
One of the most powerful features came about quite late in development: “crawling”. That is, plb<\/a><\/code><\/code> can iterate over a plist outputting paths, types and values (depending on the specified depth) and even traverse into plist data stored as data. The go-to exploratory command is: plb -V<\/code> (which is shorthand for -CCC<\/code>, the 3rd level of crawl output):<\/p>\n\n\n\n![\"\"](\"https:\/\/www.brunerd.com\/blog\/wp-content\/uploads\/image-92.png\")
<\/a>Path >>> type >>> value<\/figcaption><\/figure>\n<\/div>\n\n\nEvery simple type, except data<\/code>, can be seen above: string<\/code>, bool<\/code>, integer<\/code>, real<\/code> and date<\/code>. As well as the “complex” types of array<\/code> and dict<\/code>. An array’s indices are enumerated and a dictionary will have all paths traced with colons delimiting the path of additional dictionaries and arrays within. Let’s see what happens when we hit some data type nodes:<\/p>\n\n\n\n![\"\"](\"https:\/\/www.brunerd.com\/blog\/wp-content\/uploads\/image-93-1024x440.png\")
<\/a>Each indented section is a decoded binary blob of plist data<\/figcaption><\/figure>\n<\/div>\n\n\nAs you can see the<\/code> -V<\/code> will cause plb<\/a><\/code><\/code> to go into<\/em> property list data within data types, a lowercase -v<\/code> will not<\/em> traverse into plists encoded as data (same with upper\/lowercase crawl option -c<\/code>\/-cc<\/code> and -C<\/code>\/-CC<\/code>). When this “traversal” occurs, the path is indented for easier visual identification and the pipe character |<\/code> is used to delimit. In the above pic we can see both empty and populated arrays. There are some preferences like com.apple.ncplugin.weather<\/code> that have two levels of nesting!<\/p>\n\n\n\n![\"\"](\"https:\/\/www.brunerd.com\/blog\/wp-content\/uploads\/image-94.png\")
<\/a>Is this the “Inception” of plists?\ud83e\ude86<\/figcaption><\/figure>\n<\/div>\n\n\nLastly, here’s what binary data looks like in -v<\/code>\/-V<\/code> mode. The file<\/code> type is inside parentheses after data<\/code> and on the next line(s) are the binary data rendered with xxd<\/code><\/p>\n\n\n\n![\"\"](\"https:\/\/www.brunerd.com\/blog\/wp-content\/uploads\/image-100-1024x507.png\")
<\/a><\/figure>\n<\/div>\n\n\nMore work with embedded plist data<\/h3>\n\n\n\n
Now that we’ve checked out the “crawling” output, let’s take a look at the key that inspired all this work com.apple.gms.availability.key<\/code>. You probably won’t find this key on new<\/em> 15.4 installs but it might hang around if you upgraded from 15.0 to 15.3. In this example, if you ran defaults export .GlobalPreferences -<\/code> you’d only see the key as a base64 encoded data string and you could get just that key in XML. If you specify the key defaults<\/code> gives you an abbreviated<\/em> (and useless) hex dump. <\/p>\n\n\n\n![\"\"](\"https:\/\/www.brunerd.com\/blog\/wp-content\/uploads\/image-95.png\")
<\/a>I don’t speak robot, do you? \ud83e\udd16<\/figcaption><\/figure>\n<\/div>\n\n\nIf you use plutil<\/code> to extract the value of the key, it’d not only require some tedious escaping of the periods but would still only get you the base64 encoded string which would require piping into another plutil<\/code> command to convert to xml1<\/code>. Not to mention the -extract<\/code> syntax always throws me off!<\/p>\n\n\n\n![\"\"](\"https:\/\/www.brunerd.com\/blog\/wp-content\/uploads\/image-96-1024x212.png\")
<\/a>Two more ways to get nothing particularly useful<\/figcaption><\/figure>\n<\/div>\n\n\n![\"\"](\"https:\/\/www.brunerd.com\/blog\/wp-content\/uploads\/image-99-1024x133.png\")
<\/a>Does the “juice look worth the squeeze” in either of these options?<\/figcaption><\/figure>\n<\/div>\n\n\nPlistBuddy<\/code> can kinda<\/em> output the raw binary plist except<\/em> it appends a newline to everything<\/em>, which corrupts the binary plist data and plutil<\/code> fails. perl<\/code> can chomp it off or in zsh<\/code> you can capture the output using command substitution $()<\/code> since zsh can handle nulls in variables this will strip the extraneous newline but<\/em> again, you’d still<\/em> have to convert or extract the value plutil<\/code>! Instead<\/em>, let’s check out how easy<\/strong> it is with plb<\/a><\/code><\/code>. Let’s again start with the encoded XML output: plb -x .GlobalPreferences<\/code> com.apple.gms.availability.key<\/code> <\/p>\n\n\n\n![\"\"](\"https:\/\/www.brunerd.com\/blog\/wp-content\/uploads\/image-84.png\")
<\/a>This again but much easier to get to.<\/figcaption><\/figure>\n<\/div>\n\n\n-x<\/code> ensures XML output and<\/em> it also keeps the data from being automatically decoded and output as plaintext. How about we “traverse” into the embedded plist data and output it as XML. We simply append a pipe character |<\/code> to the end of the path, like we saw in the “crawled” paths above. Make sure to either escape or quote the pipe character in the path argument like this (so the shell does not misunderstand): plb -x .GlobalPreferences 'com.apple.gms.availability.key<\/code>|:’ (the root colon is optional, fyi)<\/p>\n\n\n\n![\"\"](\"https:\/\/www.brunerd.com\/blog\/wp-content\/uploads\/image-97-1024x189.png\")
<\/a><\/figure>\n<\/div>\n\n\nWow, this is a lot easier already! You can also crawl the key itself with -V<\/code> and get simple overview<\/p>\n\n\n\n![\"\"](\"https:\/\/www.brunerd.com\/blog\/wp-content\/uploads\/image-102.png\")
<\/a><\/figure>\n<\/div>\n\n\nSince the array has only a simple integer value, it will easily output as plain text with this command: plb .GlobalPreferences com.apple.gms.availability.key<\/code><\/p>\n\n\n\n![\"\"](\"https:\/\/www.brunerd.com\/blog\/wp-content\/uploads\/image-82.png\")
<\/a>plb<\/a><\/code><\/code>: Keeping it simple (so-and-so)<\/figcaption><\/figure>\n<\/div>\n\n\nLook at that<\/em>, would you! A simple number from a simple<\/em> command, neato! BTW: While this key might be going the way of the dodo, the value in macOS 15.0-15.3 indicates (in a roundabout way) that Apple Intelligence is off<\/strong> (2<\/code>) or on<\/strong> (0<\/code>) \u2013 1<\/code> I think means it’s downloading and installing. I built plb<\/a><\/code><\/code> to attempt to give you plaintext output by default. Only a dict<\/code> or data<\/code> key will cause output to be XML, otherwise all “simple” types are be output as plain text.<\/p>\n\n\n\nWhat’s plx for then?<\/h2>\n\n\n\n
Glad you asked! Despite making plb.min.sh<\/a> a one-liner minified version, it’s still pretty big at 18k (but down from 36k for the fully commented version!). I can understand if you are embedding that function in your script, you might want something smaller.<\/p>\n\n\n\nplx<\/a><\/code> has the essential<\/em> feature that plb<\/code> does: It can dive into nested data plists using the same colon delimited key paths and pipe characters that plb<\/a><\/code><\/code> does, it just omits some of the fancy output that plb<\/a><\/code><\/code> does but it has the most essential functions (it’s debatable they too could be removed but the functions were either small or necessary for other internal processes):<\/p>\n\n\n\n\n-l<\/code> for getting key names within a dictionary or the length of an array<\/li>\n\n\n\n- -t for getting the plist type of a node<\/li>\n\n\n\n
- -e to convert ISO 8601 dates to epoch<\/li>\n<\/ul>\n\n\n\n
This gets plx.min.sh<\/a> down below 10k! You might feel better about embedding in your script. Your call. Same easy syntax: <\/p>\n\n\n\n![\"\"](\"https:\/\/www.brunerd.com\/blog\/wp-content\/uploads\/image-98.png\")
<\/a>plx<\/a><\/code>: All the output, half the bytes (embedded in your script)<\/figcaption><\/figure>\n<\/div>\n\n\nWrapping Up<\/h2>\n\n\n\n
Check them both out at the plb GitHub repo<\/a> and the plx GitHub repo<\/a>. They both have a full sized and commented shell script as well as a one-liner\/minified version. In their Releases<\/strong> (plb<\/a>, plx<\/a>) you’ll find a macOS package (pkg) download that will install the scripts to a self-named folder in \/usr\/local\/<\/code> and then create a symlink to the main script without<\/em> the .sh<\/code> extension in \/usr\/local\/bin<\/code> so you can run it with ease! I hope you get some use out of these. <\/p>\n\n\n\nHomework<\/h2>\n\n\n\n
Make sure to check out the Advanced Examples<\/strong> in the plb -h<\/code> help output (also included down below) for some simple loops that can crawl through all<\/strong> your user prefs, you might be surprised at what you find!<\/p>\n\n\n\n#plb Advanced Examples\n#zsh only, this ignores comment lines if you copy\/paste the examples\n set -k\n\n#add to this comma separated list of large preference domains to skip\nskipDomains=\"com.apple.audio.AudioComponentCache,com.apple.SpeakSelection,com.apple.garageband10,com.apple.EmojiCache,com.apple.audio.InfoHelper\"\n\n#1 Get key paths and values for all user preferences \n# substitute `plb -D` for ByHost user prefs\nIFS=$'\\n'; for domain in $(plb -d); do\n #skip large domains\n grep -qE '(^|,)'\"${domain}\"'(,|$)' <<< \"${skipDomains}\" && continue\n echo \"## Domain: $domain\"; echo \"## File Path: $(plb -f \"${domain}\")\"; plb -V \"${domain}\"; echo\ndone\n\n#2 Get key paths and values for all .plist files in \/Library\/Preferences\nIFS=$'\\n'; for domain in $(find \/Library\/Preferences -type f -name '*plist'); do\n grep -qE \"(^|,)${domain}(,|$)\" <<< \"${skipDomains}\" && continue\n echo \"## Domain: $domain\"; echo \"## File Path: $(plb -f \"${domain}\")\"\n # Adjust the info level\/output below\n plb -V \"${domain}\"; echo\ndone\n\n# Examples 1 & 2 exercises\n # Adjust the info level\/output from -V to -CC or -C then try shallower crawls with -cc and -c\n # Output XML with `plb -x`, JSON with `plb -j`; both are speedier than crawling but with tradeoffs\n # `plb -p` prints quickly with PlistBuddy, while key\/value pairs are easily spotted, paths are not\n\n#3 Get the `file` type of all data nodes in your user prefs, you might find something interesting\nIFS=$'\\n'; for domain in $(plb -d); do\n grep -qE \"(^|,)${domain}(,|$)\" <<< \"${skipDomains}\" && continue\n echo \"## Domain: $domain\"\n echo \"## Path: $(plb -f \"${domain}\")\"\n #the sed at the end is if you use -CC, its removes the indents from the paths of data embedded plist\n for datapath in $(plb -cc \"${domain}\" | awk -F ' >>> ' '\/data$\/ {print $1}' | sed 's\/^ *\/\/'); do \n #get file type of data and key path\n echo \"$(plb -F \"$domain\" \"$datapath\") <<< ${datapath}\"\n done\n echo\ndone\n\n# Example 3 notes: \n # `plb -cc` does not go into data plists, use `plb -CC` to search within data plists\n # Use the awk field separator `-F ' >>> '` to easily parse -cc\/-CC output ($1 paths, $2 type)\n<\/code><\/pre>\n","protected":false},"excerpt":{"rendered":"Elevator pitch I’m excited to introduce two plist tools for macOS plb the plist broker and plx the plist extractor. The value of plb is its ability to visualize a plist as you will see below, just like my tool jpt does for JSON. plb can map out the complete paths and values that may […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[19,70,71,40,12,39],"tags":[20,66,69,67,68,24,23],"class_list":["post-1570","post","type-post","status-publish","format-standard","hentry","category-bash","category-plb","category-plx","category-projects","category-scripting","category-zsh","tag-bash","tag-plb","tag-plist","tag-plx","tag-sh","tag-shell","tag-zsh"],"_links":{"self":[{"href":"https:\/\/www.brunerd.com\/blog\/wp-json\/wp\/v2\/posts\/1570","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.brunerd.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.brunerd.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.brunerd.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.brunerd.com\/blog\/wp-json\/wp\/v2\/comments?post=1570"}],"version-history":[{"count":31,"href":"https:\/\/www.brunerd.com\/blog\/wp-json\/wp\/v2\/posts\/1570\/revisions"}],"predecessor-version":[{"id":1687,"href":"https:\/\/www.brunerd.com\/blog\/wp-json\/wp\/v2\/posts\/1570\/revisions\/1687"}],"wp:attachment":[{"href":"https:\/\/www.brunerd.com\/blog\/wp-json\/wp\/v2\/media?parent=1570"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.brunerd.com\/blog\/wp-json\/wp\/v2\/categories?post=1570"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.brunerd.com\/blog\/wp-json\/wp\/v2\/tags?post=1570"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}