Defaults Read

How do I refine the following script to get only the height and width? I’m sure that there has to be a way to hone in on them without using grep or some other convoluted parse routine but I don’t know the syntax of the defaults command to make it happen.

do shell script "defaults read /Library/Preferences/ DisplaySets"

Thanks for any info that you might offer. :slight_smile:

This is close but not quite there…

defaults read /Library/Preferences/ DisplaySets | grep -w Width

I need to figure out a way to do both ‘Width & Height’ and have it return the first occurrence only.

I really appreciate your effort Greg but I don’t want to use grep. I’m more interested in finding out if there’s a way to use only the defaults read command to extract the specific info that is needed, no matter how many levels deep in the plist it is buried. I find it hard to believe that this can’t be done but I haven’t found any examples so I’m beginning to wonder. :slight_smile:


I should have read your post a little closer ;¬)

Take a look at ‘man defaults’, I’ve read thru it but can’t offer any help.

Try this, just do the same for width

--Read the prefs
set thePrefs to do shell script "defaults read /Library/Preferences/ DisplaySets"
--Get the Height
set getHeight to the offset of "Height" in the thePrefs
set heightValue to (characters (getHeight + 9) thru (getHeight + 12) of the thePrefs) as text

--show the height
display dialog "Height = " & heightValue

Thanks Andy. I guess using the defaults read command for the entire task is out of the question. :confused:

If all your trying to do is to get the bounds of the desktop, Apple’s Gui Scripting page has this script

copy my desktop_size() to {desktop_width, desktop_height}

on desktop_size()
	tell application "System Events"
		tell process "Finder"
			repeat with i from 1 to the count of windows
				if the position of window i is {0, 0} then
					return the size of window i
				end if
			end repeat
		end tell
	end tell
end desktop_size

Extra Suites has a script for this too…

tell application "Extra Suites"
	set screenInfo to screen info
	set theWidth to width of screenInfo
	set theHeight to height of screenInfo
	set theDepth to depth of screenInfo
end tell

display dialog "Width: " & theWidth & return & "Height: " & theHeight & return & "Depth: " & theDepth buttons "OK" default button 1 with icon 1

While getting the bounds of the desktop was the original goal (I was helping someone else), my main goal became finding out if the defaults read command could work on a more granular basis. I’ve run into other cases where it would be extremely handy to be able to grab one tiny bit of info from a plist without jumping through a bunch of hoops to do it. While parsing results works fine, I’m afraid that it might be too fragile to depend on. :slight_smile:

‘man defaults’ pretty much answers that:

Ideally you want to use an official Apple API for working with plists, but this may not always be practical and sometimes you have to hack it. One thing you could try is my PListLib library. Converts plists to object models, and vice-versa. Unfinished, but should be okay for most stuff. Oh, and remember that plist files are UTF-8, so read them using ‘read plistFile as «class utf8»’ (AS1.9+) to avoid spoiling non-ASCII characters.

Thanks HAS! I’ve downloaded your plist library for a test drive. I remember seeing it but had completely forgotten about it. I still think it’s a shame that the defaults write command can generate something so complex that the defaults read command can’t break it down. :?

No, it’s not that. defaults’ read and write options both provide very basic interfaces that aren’t designed for manipulating hierarchical data directly. The complex plists you’re trying to manipulate are generated by applications using Core Foundation APIs, which are much more powerful. However, unless you’re working in Studio you won’t have any access to these APIs (not unless you’re willing to write your own osax), so you’re stuck with using either ‘defaults’ (which is only good for simple stuff) or a home-grown solution (which also has some issues of its own).

Mind you, stuff like getting and setting monitor resolution ought to be part of the standard additions anyway; having to trail through other apps’ undocumented plist structures is, at best, an almighty kludge. All I can suggest is more folk go submit feature requests; if Apple know something is important to a lot of users they may bump it up the priority list and get it done sooner.