I’ll admit it: I’m a bit slow when it comes to the shell. I use it a lot, but never feel like I’m using it as well as I could. But today, I ﬁgured out how to turn on Z Shell completion system. And it is very, very good.
This guide helped me, leading me to add the following to my .zshrc ﬁle:
autoload -U compinit
Once I’d done that, I could begin completing various commands and parameters. Within a few moments, using the tutorial above, I’d already completed:
This is cool.
When scripting for system administration, it’s often helpful to know what edition and version of Mac OS X is installed.
By edition, I mean whether you are using Mac OS X or Mac OS X Server — Server generally being a superset of the client operating system. The version, of course, is an indentiﬁer such as “10.4.9” or “10.3” or “10.2.8.”
Given the version number, you can deduce the marketing name of the system software: “Tiger,” “Panther,” and “Jaguar,” respectively. Interestingly, I’m aware of no string in the system that identiﬁes that marketing name; even “About This Mac” in the Apple menu does not display it. (However, you can ﬁnd all of the names in the Mac OS X entry in Wikipedia.)
You can obtain the version information in a number of ways. From a scriptability standpoint, the quickest way to the chase is probably the
sw_vers utility. The basic usage and output looks like this:
ProductName: Mac OS X
… but you can also, as of Mac OS X 10.3 or later, narrow it down to get just the string you want. (Note that you can only run
sw_vers, without modiﬁcation, in Jaguar and earlier.) So, if you just need the ProductVersion, ask for it:
$ sw_vers -productVersion
One drawback of this solution is that you can only get the version information for a running copy of Mac OS X. According to its man page,
“prints version information about the Mac OS X or Mac OS X Server operating
system running on the local machine.” It can’t detect the version of a
non-running Mac OS X installation.
Happily, the same information is stored in two property list ﬁles in the /System directory. Therefore, you can read the version data directly from these plist ﬁles.
… where $volume is the path to the target volume. The ServerVersion.plist ﬁle does not exist on workstation/client edition of Mac OS X. The mere presence of the ServerVersion.plist, therefore, indicates that you have encountered Mac OS X Server.
So, from the command line, you could enter:
$ defaults read /System/Library/CoreServices/SystemVersion 'ProductVersion'
… or even …
$ defaults read '/Volumes/Mac OS X Install DVD/System/Library/CoreServices/SystemVersion' 'ProductVersion'
Reading the plists comes in handy if you’re trying to detect the version of Mac OS X on a disk other than the current startup disk, where
sw_vers fails. This means you can even detect the version of Mac OS X installed on Apple’s boot CDs and DVDs!
The plist method is also useful if you’re using a scripting language — such as Python, with its plistlib module (I’m sure there’s something for Perl, too … and you could also try
defaults as above) — that can read them. If the ﬁles can be read directly, you don’t need to call out to a shell command, even one as simple as
defaults, from within the scripting language. That means you won’t be spawning an additional process, and your scripts can therefore gain a slight speed increase.
Here is example
defaults output from a running Mac OS X workstation (a Core 2 Duo-based MacBook Pro):
ProductBuildVersion = 8P2137;
ProductCopyright = "1983-2007 Apple Inc.";
ProductName = "Mac OS X";
ProductUserVisibleVersion = "10.4.9";
ProductVersion = "10.4.9";
And from a Tiger install DVD, originally for PowerPC:
ProductBuildVersion = 8A428;
ProductCopyright = "1983-2005 Apple Computer, Inc.";
ProductName = "Mac OS X";
ProductUserVisibleVersion = "10.4";
ProductVersion = "10.4";
To show that this is not a ﬂuke, here’s the same result from a Panther install CD (you must use Disc 1, as it is the startup disc in the set):
ProductBuildVersion = 7B85;
ProductCopyright = "Apple Computer, Inc. 1983-2003";
ProductName = "Mac OS X";
ProductUserVisibleVersion = "10.3";
ProductVersion = "10.3";
I expect that this applies all the way back to Mac OS X 10.0 from March 24, 2001. To date, though, I’ve veriﬁed this behavior as far back as a Jaguar install CD:
ProductBuildVersion = 6C115;
ProductCopyright = "Apple Computer, Inc. 1983-2002";
ProductName = "Mac OS X";
ProductUserVisibleVersion = "10.2";
ProductVersion = "10.2";
Update: I did run the same test on a Mac OS X 10.0 install CD from 2001. The results show that you can use the property list reading method to obtain the version information for any release of Mac OS X:
ProductBuildVersion = 4K78;
ProductName = "Mac OS X";
ProductVersion = "10.0";
However, note that the ProductUserVisibleVersion and ProductCopyright keys are not in the plist of the Cheetah system.
The information above was adapted from my+similar+post+on+the+MacEnterprise+list.
Does anyone else see the massive+honey+bee+die-oﬀ as some twisted re-imagining of the dolphins leaving Earth in the Hitch Hiker’s Guide to the Galaxy? Hm.
Continuing today’s Drupal love, I should mention that I recently ﬁgured out how to use the Inline module. Thanks to Inline, I’ve gotten much closer to the more-ideal state I felt I had with the built-in facilities of Userland Manila in 1999.
Namely, I adored Manila’s easy interlinking of pages. I could just quote the name of one page while in the body text of a second page, and the quoted title would become a link between them when published. I could also put images inline by quoting their titles in the body text of a page. It made the rapid creation of new, richly-linked sets of pages very fast and, while not eﬀortless, much easier. I’ve used that to good eﬀect, I think, in some past projects.
Drupal’s Inline module allows me to do much the same today. It uses double square brackets, which aren’t as convenient as quotes, but it gives me additional power I always wished Manila had. I can place the titles of pages on my site inside the double backets, to link between pages internally. I can also put the URLs of outside pages in those brackets, to link externally. I can also modify this by putting a pipe between the title or URL, and the link text that I want the reader to see on the page. This is very ﬂexible, and that last ability really overcomes an obstacle I ran into with Manila — without the opportunity to change the link text, I ended up having some oddly-capitalized links within sentences.
I have had the urge to adjust the automatically-generated paths that Drupal’s Pathauto module provides for each story I post. Today, I took a quick look at Pathauto after some brief Web searches on this topic, and found that making changes was remarkably easy.
New articles I post to Irreality will now have a default path that corresponds to the year, month, and day, followed by the article title. Therefore, I can predict that this article will end up being at “/2007/05/03/pathauto_and_custom_paths.”
Thanks to the facilities in Pathauto, I’ve also generated:
It wasn’t obviously to me how to do all of this upfront, but the power of Drupal is really growing on me as I learn more tidbits like this.
From Python 2.3.5, installed by default in Mac OS X Tiger:
>>> import sys
['', '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python23.zip', '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3', '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/plat-darwin', '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/plat-mac', '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/plat-mac/lib-scriptpackages', '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/lib-tk', '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/lib-dynload', '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages', '/System/Library/Frameworks/Python.framework/Versions/2.3/Extras/lib/python']
>>> for z in sys.path:
... if '2.3' not in z:
>>> import sys
['', '/Library/Frameworks/Python.framework/Versions/2.5/lib/python25.zip', '/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5', '/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/plat-darwin', '/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/plat-mac', '/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/plat-mac/lib-scriptpackages', '/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-tk', '/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload', '/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages']
>>> for z in sys.path:
... if '2.5' not in z:
This simply means there are no directories in common in sys.path — the list of directories where modules can be installed — between these two versions of Python. I ﬁnd that a bit annoying, since I can’t by default count on deploying one module to a single location that will work in both the default and upgraded versions of Python.
That lack of a default common location also has an impact if you’re managing the ﬁlesystem with Radmind.
Yesterday, I thought I’d came across a potential solution to a problem I’d been having with restoring disk images to target drives using Disk Utility. I keep getting error 22, “invalid argument,” when restoring images over HTTP, using Disk Utility on the original Tiger version of the Mac OS X Install DVD.
While there could be some form of image ﬁle corruption, restoring the same images locally — over FireWire target disk mode, for example — appears to succeed reliably and repeatedly. (See also this+Shirt+Pocket+Software+thread, where the core error was also not resolved.)
Let’s say that you have your images stored on a Web server — preferably one with some access controls, because you don’t want your system images open to just anyone. That should let you use Apple Software Restore’s HTTP-based image restore feature. You have already prepped the images for ASR, creating them appropriately (possibly through the use of shadow ﬁles) and applying the volume-level checksum that is required for block-level restores.
However, let’s assume that your naming convention for system images includes more than one period. After all, you’re creating images for Mac OS X versions like 10.3.9 and 10.4.8 … it’s natural to want to use those version numbers somewhere in your system image names. There’s no sense in changing those periods to some other character, right?
Well, I surmised there might have been a reason to change or remove those periods. I expected that removing — or encoding with %2e (as noted in this URL encoding reference) — the periods from a test image’s name would have a beneﬁcial eﬀect, to let me restore it successfully via HTTP. However, it was still a no-go with the encoded characters, so I’m now back where I started. The image restoration works until near the end of the process, and I get error 22 again. Grr.
I’m wondering out loud now whether there’s a problem with automount, since I’ve seen some search results that seem to mention error 22 in conjunction with it. I have no clue why it would fail only for HTTP-based ASR restores using a Tiger install DVD, though.
It seems I can recall the restore-via-HTTP feature working at some point in the past, but it certainly hasn’t done so to my recollection under Tiger.
I’d been having problems for several weeks, maybe months, with printing out some kinds of documents from my oﬃce MacBook Pro. I’d send the print jobs to our trusty Xerox WorkCentre Pro 55, and I’d get one copy of the document. This was okay when I only wanted one copy. But, I’d increasingly had a need for several … so defaulting to one just made it diﬃcult to get multiple original copies (or “mopies,” I guess, if you subscribe to HP-lingo) when I needed them.
This problem seemed to spread from PDFs in Safari, to all PDFs, and then to other document types — including, most recently, documents printed directly from Microsoft Word 2004. At this point, I became aggravated enough that I tried some very minimal troubleshooting, which quickly led nowhere. I just wanted this to work.
So, I took the shotgun approach. I hate doing this, because I want to know the whys and wherefores of problems. I want to apply the scientiﬁc method to ﬁnding and resolving the issue at hand. I want to prevent the problem from appearing again. In this case, though, I just needed to print … and I resorted to the “Reset Printing System” menu command in Printer Setup Utility.
Voilá! That let me print multiple copies of my Word ﬁles again. Great!
I next tried a PDF that had failed to print completely before. I’ve had success with that, as well. Excellent.
Therefore, if you know the deﬁnitions for your printers — because the “Reset Printing System” command in Tiger will delete your print queues and force you to re-add them — then the reset option can resolve some strange problems and get you back in working order.
When deploying system software with disk images, it is helpful to have various checkpoint images that you can revert to while you’re building up a fully-ﬂedged template computer. This is something they teach you in school (really, I was taught it in a systems administration class) and it’s more or less encoded in the solution accelerator documentation for Microsoft’s Business Desktop Deployment 2007 for Windows.
However, if you’re updating images, keeping the base and intermediate images can strain your storage capacity. Mac OS X lacks the compelling live editing features of Microsoft’s new WIM image format — which if it had appeared ﬁrst on the Mac, I’d be trumpeting loudly, so I feel compelled to at least give a nod to Microsoft here.
Since I’m always struggling with storage capacity and I prefer having an up-to-date base image, I thought about this problem a bit in the context of Mac OS X imaging and have come upon what seems to be a unique solution: the use of shadow ﬁles.
Here’s the basic idea:
Congratulate yourself on this use of shadow ﬁles, because you’ve saved at least one intermediate step and the space required for a full read-write disk image — or worse, an extra local partition needed only for restoration and updating the base image.
Unmount that volume and throw away the shadow ﬁle at this point if you want, because you’ve now got two system images ready for deployment. One has the base system software, and serves as a checkpoint that you can return to later; it’s the base for all future updates of that major revision of Mac OS X. The other image has the latest version of Mac OS X. If you’re deploying that image with ASR, the result will be a more secure system because it’s closer to being fully patched — and it should take less time to update it with the additional security updates and application installs — whether you use installers or Radmind or another solution — because you’ve got the bulk of the operating system done.
Unfortunately, many updates can only be installed on the startup disk and thus cannot be included in the updated base image. Beyond the combo operating system updates, few of Apple’s other installers will work on a non-startup volume. But you can install them after deploying the updated base image, using your tool of choice. For reasons like this, Geoﬀ doesn’t see updating the base image as valuable, but in some IT environments, it may be very worthwhile.
My next step is to script this process and tie it to a watched folder. Imagine dropping a combo update into a watched folder … and letting a script generate the new, updated image for you.
Nadyne writes about her pet peeve #1, which involves people writing “MAC” instead of “Mac.” This is also a frustration of mine, and others don’t always see it until you explain it to them in terms that are closer to their own experience.
My corollaries to Nadyne’s comments are:
[Via go ahead, mac my day.]