Date
1 - 10 of 10
Defaults CLI Not Working on Files
Keary Suska
We used to be able to use the defaults command to read/write plist files, but that doesn’t seem to be working anymore on my OS 12.6.1 machine. There is a note of deprecation plans for this feature, and that there will be a replacement, but the online docs don’t say anything about this. Anybody know?
TIA,
Keary Suska
Esoteritech, Inc.
"Demystifying technology for your home or business”
TIA,
Keary Suska
Esoteritech, Inc.
"Demystifying technology for your home or business”
Marco S Hyman
On Nov 15, 2022, at 5:03 PM, Keary Suska <cocoa-dev@...> wrote:
defaults read/write work on my machine (13.0.1) but not necessarily immediately updating a plist file. Current defaults are cached, controlled by cfprefsd (I think). If you want to go directly to a plist file I might use PlistBuddy.
We used to be able to use the defaults command to read/write plist files, but that doesn’t seem to be working anymore on my OS 12.6.1 machine.
Mark Allan
On 16 Nov 2022, at 1:19 am, Marco S Hyman <marc@...> wrote:On Nov 15, 2022, at 5:03 PM, Keary Suska <cocoa-dev@...> wrote:
We used to be able to use the defaults command to read/write plist files, but that doesn’t seem to be working anymore on my OS 12.6.1 machine.
defaults read/write work on my machine (13.0.1) but not necessarily immediately updating a plist file. Current defaults are cached, controlled by cfprefsd (I think). If you want to go directly to a plist file I might use PlistBuddy.
Yeah, you have to kill cfprefsd for any changes to take effect, but I agree with Keary, PlistBuddy is the tool you're looking for. It takes a bit of learning (and has some niggly bugs) but it's much more powerful than the defaults command. You'll find it at /usr/libexec/PlistBuddy
Mark
Mark Allan
On 16 Nov 2022, at 10:52 am, Mark Allan via groups.io <markjallan@...> wrote:Apologies for the HTML email, and for getting the name wrong. I meant "I agree with Marco"...On 16 Nov 2022, at 1:19 am, Marco S Hyman <marc@...> wrote:Yeah, you have to kill cfprefsd for any changes to take effect, but I agree with Keary, PlistBuddy is the tool you're looking for. It takes a bit of learning (and has some niggly bugs) but it's much more powerful than the defaults command. You'll find it at /usr/libexec/PlistBuddy
On Nov 15, 2022, at 5:03 PM, Keary Suska <cocoa-dev@...> wrote:defaults read/write work on my machine (13.0.1) but not necessarily immediately updating a plist file. Current defaults are cached, controlled by cfprefsd (I think). If you want to go directly to a plist file I might use PlistBuddy.
We used to be able to use the defaults command to read/write plist files, but that doesn’t seem to be working anymore on my OS 12.6.1 machine.
Mark
Simon Manning
There is also
plutil which is more recent, I think a replacement for PlistBuddy though I don't remember where I'm getting that idea from, and in the default PATH.When
defaults gained the caching behaviour, or perhaps started caching more aggressively, plutil is what I moved over to using for build scripts that manipulate Info.plist during an Xcode build.Simon
Keary Suska
My issue is that I am trying to update an old installation script (not one I wrote) without having to rewrite it. It uses defaults to read values from an Info.plist file, but those command fail with the error "The domain/default pair of ... does not exist” even though the key does in fact exist. It looks like it is interpreting the file name path as a domain, and of course that wouldn’t exist (which makes the error even less useful).
So, if I could do a global search and replace to change those commands, that would be much easier, hence my question. So to switch that around, does anyone know of a command line utility that allows one to read values by key from a plist file?
Keary Suska
Esoteritech, Inc.
"Demystifying technology for your home or business”
toggle quoted message
Show quoted text
So, if I could do a global search and replace to change those commands, that would be much easier, hence my question. So to switch that around, does anyone know of a command line utility that allows one to read values by key from a plist file?
Keary Suska
Esoteritech, Inc.
"Demystifying technology for your home or business”
On Nov 16, 2022, at 5:12 AM, Simon Manning <simon.manning@...> wrote:
There is also plutil which is more recent, I think a replacement for PlistBuddy though I don't remember where I'm getting that idea from, and in the default PATH.
When defaults gained the caching behaviour, or perhaps started caching more aggressively, plutil is what I moved over to using for build scripts that manipulate Info.plist during an Xcode build.
Simon
Marco S Hyman
On Nov 16, 2022, at 9:27 AM, Keary Suska <cocoa-dev@...> wrote:% /usr/libexec/PlistBuddy -c "Print LSApplicationCategoryType” Info.plist
does anyone know of a command line utility that allows one to read values by key from a plist file?
public.app-category.photography
I didn’t know about plutil until I read Simon’s response. I’ll be giving it a look.
Marc
James Walker
On Nov 16, 2022, at 9:27 AM, Keary Suska <cocoa-dev@...> wrote:If you are using a path as a domain, did you quote it if it contains any spaces? I just tried defaults read <path> <key> in a case where the path is a full path that does not contain spaces, and it worked.
My issue is that I am trying to update an old installation script (not one I wrote) without having to rewrite it. It uses defaults to read values from an Info.plist file, but those command fail with the error "The domain/default pair of ... does not exist” even though the key does in fact exist. It looks like it is interpreting the file name path as a domain, and of course that wouldn’t exist (which makes the error even less useful).
Alex Zavatone
Spaces or other characters such as ‘, “ or cyrillic.
toggle quoted message
Show quoted text
On Nov 16, 2022, at 5:10 PM, James Walker <list2@...> wrote:On Nov 16, 2022, at 9:27 AM, Keary Suska <cocoa-dev@...> wrote:If you are using a path as a domain, did you quote it if it contains any spaces? I just tried defaults read <path> <key> in a case where the path is a full path that does not contain spaces, and it worked.
My issue is that I am trying to update an old installation script (not one I wrote) without having to rewrite it. It uses defaults to read values from an Info.plist file, but those command fail with the error "The domain/default pair of ... does not exist” even though the key does in fact exist. It looks like it is interpreting the file name path as a domain, and of course that wouldn’t exist (which makes the error even less useful).
Keary Suska
No spaces or special characters—defaults echoes back the path and key so I know it is recognizing them. I quoted them both anyway, with the same results.
The PlistBuddy suggestion, however, works. Thanks Alex! I looked at the help output for PlistBuddy as other had recommended it but I didn’t grok this option. Just a “duh” moment.
Thanks all,
Keary Suska
Esoteritech, Inc.
"Demystifying technology for your home or business”
toggle quoted message
Show quoted text
The PlistBuddy suggestion, however, works. Thanks Alex! I looked at the help output for PlistBuddy as other had recommended it but I didn’t grok this option. Just a “duh” moment.
Thanks all,
Keary Suska
Esoteritech, Inc.
"Demystifying technology for your home or business”
On Nov 16, 2022, at 1:22 PM, Alex Zavatone via groups.io <zav@...> wrote:
Spaces or other characters such as ‘, “ or cyrillic.On Nov 16, 2022, at 5:10 PM, James Walker <list2@...> wrote:On Nov 16, 2022, at 9:27 AM, Keary Suska <cocoa-dev@...> wrote:If you are using a path as a domain, did you quote it if it contains any spaces? I just tried defaults read <path> <key> in a case where the path is a full path that does not contain spaces, and it worked.
My issue is that I am trying to update an old installation script (not one I wrote) without having to rewrite it. It uses defaults to read values from an Info.plist file, but those command fail with the error "The domain/default pair of ... does not exist” even though the key does in fact exist. It looks like it is interpreting the file name path as a domain, and of course that wouldn’t exist (which makes the error even less useful).