Byte summary case isn't handled

[catilac]

When parsing the output of the command defaults read this parser breaks when going over what I'm calling "byte summaries"

It looks like this:

keyName = {length = 1163, bytes = 0x62706c69 73743030 d4010203 04050607 ... 00000000 00000397 };

I think it would be sufficient to parse this as a dictionary, and treat the bytes key as a string. What do you think? Happy to build this functionality, but will wait for your feedback :)

Thanks!

[DHowett]

Thanks for the request!

So, here's the problem with defaults: the output from defaults is not a property list. It pretends to be one, but it doesn't follow a number of the basic formatting rules. It's just not a recognizable property list format. I'm not sure that I want to add support for various not-actually-plist formats to the plist library :smile:

I have to ask, though: the input to defaults is a property list file. Why not just parse the property list directly instead of asking defaults to convert it and then trying to parse it after defaults is done with it? It's a middleman that is effectively corrupting the data. By skipping it, you'll get more reliable results and you're guaranteed that that data is in the right format.

[catilac]

ah! i definitely see what you mean. defaults read gives a giant blob of "plist" defaults data for all the domains. would you be open to a mode that can manage this weird output? Being able to use defaults read gets me exactly what i'm looking for, without having to scan for plist files.

[DHowett]

That's a fair point. It might be worth having a smaller separate package that just takes the text plist parsing code out of this one and handles defaults' output 😄

That way, users don't have to have a bunch of XML/Binary parsing they don't need, and this package can keep up with the plist standard without worrying about breaking defaults' parsing!

[catilac]

Sounds good! :)