defaults was there in 10.6 so you can still use it.

defaults was there from the beginning of OS X. Actually even earlier - the defaults man page indicates it was in NeXTStep, which is what OS X was born from.

I'm working on remote machines, so I guess the target plist file or value doesn't exist on the 10.6.8 machines.
For the record I was looking at the info.plist file for a number of apps for monitoring so not sure why they wouldn't exist.
It's not too big a deal as we only have 5 of them left in our environment and a better solution is to eliminate these!
Thanks for the quick response guys.

I've sometimes seen defaults give that no domain/key error
you could use plist buddy

For example:

/usr/libexec/PlistBuddy -c "Print :Text1" /Library/Preferences/com.apple.RemoteDesktop.plist

Will give you the content inside the Text1 key, to see all the keys in there you can just do:

/usr/libexec/PlistBuddy -c "Print" /Library/Preferences/com.apple.RemoteDesktop.plist

@Look i think the issue may be that back in 10.6, defaults required that the plist be specified without the .plist extension. So for example, in the command, don't use Info.plist, just cut it short at Info
Starting with 10.7, either way could be specified and defaults would work fine, but it was more picky from 10.6.x and earlier.

Didn't 10.7 do some kind of half way house? I always found 10.7 to be inconsistent

root# sw_vers
ProductName:    Mac OS X
ProductVersion: 10.7.5
BuildVersion:   11G63
mc1020:~ root# whoami
root
mc1020:~ root# defaults read /Library/Preferences/com.microsoft.PlayReady
{
    "SOFTWARE\\\\Microsoft\\\\PlayReady" =     (
                {
            DataPath = "/Library/Application Support/Microsoft/PlayReady";
        }
    );
}
mc1020:~ root# defaults read /Library/Preferences/com.microsoft.PlayReady.plist 
2015-07-23 12:42:00.618 defaults[26792:707] 
Domain com.microsoft.PlayReady.plist does not exist
mc1020:~ root# defaults read /Library/LaunchDaemons/com.apple.remotepairtool.plist 
{
    Label = "com.apple.RemotePairTool";
    MachServices =     {
        "com.apple.RemotePairTool" = 1;
    };
    Program = "/System/Library/CoreServices/RemotePairTool";
}

Beware with 10.6 though. If you write to a plist file with defaults and you include the plist extension, you will end up with a file called 'MyFile.plist.plist'

If you try and read a plist using the incorrect/unexpected file name or you try and read a file you don't have permissions to read, then you get the domain does not exist error. However, if you are getting a domian/default pair does not exist message, then that would imply that the key you are trying to read really doesn't exist.

You could be right @sean. My memory of things from 10.7 and earlier is beginning to fade so its possible 10.7 was still in transition to the new way. I do know that for sure with 10.6 and earlier you could not specify a plist with the actual extension included the way you can today. It just wouldn't work, and then somewhere along the line, Apple made it work both ways. It wasn't even a well documented change if I recall. I think most folks just stumbled upon the fact that defaults was suddenly OK with using .plist in the path to the file.

Hi -

I've seen this working on remote machines before. Remember that this tool assumes you know where the plist file you are trying to access is located and it starts out in the user home directory where you run the tool. So, if you log in as say netadmin then it goes into the prefs library for that user. Which would be cool, but you probably mean to fix the permissions for the user that your trying to help remotely. Give defaults the full path to the plist your trying to edit and you should be just fine. Something like...

defaults read /Users/<username>/Library/Preferences/com.apple.<app of your choice> <setting>

Been there done that... Unix is sooo literal. No sense of humor. ;-)

You might want to check out the command plutil convert.... Then you can convert the plist and just edit the XML with your favorite scripting tool. Like python!

Wayne

BringBackDefaults + 1

@mm2270

I'll try it without the extension for the 10.6 machines.
Otherwise it is working consistently across all over versions.