I occasionally stumble upon such secret troves of knowledge, but I'd love to find out how these are discovered.
Is there, like, a way to intercept all `defaults`/settings reads to discover what keys are checked?
I occasionally stumble upon such secret troves of knowledge, but I'd love to find out how these are discovered.
Is there, like, a way to intercept all `defaults`/settings reads to discover what keys are checked?
`defaults read > old` -> change setting in GUI -> `defaults read > new` -> `diff old new`
If nothing is there, you're out of luck, most likely. (I think I've had luck using -currentHost or maybe sudo sometimes though...) If there is something, `less new` and search for the string, then find the path to the key. Do a test read with `defaults read <domain> <item>` to see if you got the path right.
You can also copy plist files (cp -r /Library/Preferences, or wherever) and then diff those. A useful alias to convert to xml:
alias plist='plutil -convert xml1 -o /dev/stdout'
This doesn't help with "secret" settings that aren't exposed through the UI, but can be handy for creating setup scripts.
Skimming this list right now a lot of the stuff I'm seeing definitely has UI settings, so a lot of these are just useful for e.g. automating the setup of a new user.
In practice, people probably just read user defaults and try to reverse engineer what they do.
CGFontRenderingFontSmoothingDisabled
is. I tried defaults read CGFontRenderingFontSmoothingDisabled
but got: Domain CGFontRenderingFontSmoothingDisabled does not exist defaults read | grep CGFontRenderingFontSmoothingDisabledYou can see a huge list of settings by typing „defaults read“
For example, the NSToolbarTitleViewRolloverDelay setting, while valid per the article, isn't listed in the output of `defaults read`