As promised, here’s the second installment of interesting Mac OS X command line tools. See the first installment here. There’s quite a heavy focus on reading out information about the configuration of your computer, but plenty of other tools are detailed as well…
- findsmb (find Server Message Block hosts)
- osascript (Open Scripting Architecture script runner)
- sips (scriptable image processing system)
- $sips -g all picture.png retrieves a selection of metadata from an image, including Spotlight attributes such as kMDItemAcquisitionModel, kMDItemProfileName and kMDItemColorSpace. Strangely, mdls reports considerably more information, including attributes such as kMDItemExposureTimeSeconds and kMDItemFocalLength.
- $sips -r 90 picture.png rotates the image 90 degrees clockwise.
- $sips -f vertical picture.png flips the image across its vertical axis.
- $sips –setProperty format jpeg picture.png changes the image from whatever format it is currently in (in this case PNG) to a JPG.
- $sips –setProperty copyright “Richard Pollock” picture.jpg sets the image “copyright” property to “Richard Pollock”.
This one definitely isn’t unique to Mac OS X, but can be very useful all the same. findsmb, located in /usr/bin/, is a perl script, which ships as part of the Samba suite. Called with no options, it runs a nmblookup ‘*’ and then feeds the output into a smbclient -L $netbiosname -I $ipaddress -N. The options basically mean: look up information for the machine with this (-L) netbiosname and this (-I) IP address (both are specified just in case the netbiosname doesn’t match up with the TCP/IP DNS host names) and don’t ask for a password (-N). The result looks something like this:
AnonymousÂ loginÂ successful
Domain=[WORKGROUP]Â OS=[Unix]Â Server=[SambaÂ 3.0.10]
SharenameÂ Â Â Â Â Â Â TypeÂ Â Â Â Â Â Comment
---------Â Â Â Â Â Â Â ----Â Â Â Â Â Â -------
IPC$Â Â Â Â Â Â Â Â Â Â Â Â IPCÂ Â Â Â Â Â Â IPCÂ ServiceÂ (MyÂ iMac)
ADMIN$Â Â Â Â Â Â Â Â Â Â IPCÂ Â Â Â Â Â Â IPCÂ ServiceÂ (MyÂ iMac)
The first line of this output is reported by the findsmb script, along with the IP address and netbios name of every computer returned by nmblookup ‘*’. Potentially very useful.
sysctl is a powerful tool introduced in 4.4BSD for viewing (and in some cases modifying) advanced system settings, including those relating to the TCP/IP stack, virtual memory and the CPU. It is an analogous to the proc file system on Linux. Running $sysctl -a | less shows a list of all the available properties, styled as a so-called Management Information Base (MIB) – the hierarchical dotted notation shown below. On my system, sysctl -a currently returns 384 values, including (as an example) the following information about current virtual memory usage:
vm.loadavg: 0.15 0.20 0.16
vm.swapusage: total = 3072.00M used = 2304.75M free = 767.25M
Incidentally, the same information can be obtained by running sysctl vm, which retrieves all values from the specified MIB domain.
Individual values can also be obtained simply by specifying the MIB name, for example $sysctl -n machdep.cpu.brand_string returns the brand of CPU (the -n flag returns the value only, rather than the MIB-value pair):
Intel(R) Core(TM)2 CPU T7600 @ 2.33GHz
To set a value using sysctl, the -w option must be used, followed by a name=value pair. So, to blatantly copy an example from the man page, $sysctl -w kern.maxproc=1000 would set the maximum number of processes on the system to 1000 and $sysctl -w net.inet.ip.forwarding=1 would turn on IP forwarding.
Bonus sysctl tip: $sysctl kern.boottime shows the time and date when the system was last booted, negating the need for any awkward calculations from the output of the uptime command.
This command takes no options and basically just performs a small subset of sysctl functionality in that it reports information about the current computer configuration. It can be thought of as a more detailed version of the “About This Mac” item in the Apple menu. The output is in the following format:
Mach kernel version:
Darwin Kernel Version 8.8.2: Thu Sep 28 20:43:26 PDT 2006; root:xnu-792.14.14.obj~1/RELEASE_I386
Kernel configured for up to 2 processors.
2 processors are physically available.
2 processors are logically available.
Processor type: i486 (Intel 80486)
Processors active: 0 1
Primary memory available: 2.00 gigabytes
Default processor set: 86 tasks, 314 threads, 2 processors
Load average: 0.20, Mach factor: 1.78
Basically, this is the same as running $uname -v; sysctl hw.physicalcpu; sysctl hw.logicalcpu; machine; sysctl hw.activecpu; sysctl hw.physmem; top -l 1 | grep Proc; top -l 1 | grep Load;, but it’s a bit neater and, crucially, is much faster to type!
This one’s definitely unique to OS X and is the CLI equivalent of Apple’s GUI-based System Profiler (in /Applications/Utilities/). It replaced AppleSystemProfile as the CLI system-profiling tool of choice in Mac OS X 10.3 (I think). It doesn’t have many options, but the level of output detail can be varied (slightly) using the -detailLevel option followed by mini, basic or full. I’m not exactly sure whence all the information is gleaned, but I notice that it links to a private Apple framework called SPSupport.framework, which clearly has something to do with it…
The only other interesting functionality in system_profiler is the ability to output all the information as an XML file ($system_profiler -xml), which can then be imported into the UI System Profiler for viewing.
Another tool found only on Mac OS X, osascript allows for the execution of Applescripts from the command line. With the addition of Philip Aker’s brilliant OSAComponents, Perl, PHP, Python, Ruby, sh, and Tcl scripts are all placed at “peer level” with Applescript with the implication that they can also be run by osascript and indeed saved in .scpt files, .scptd bundles or even application bundles.
osascript can run a script in three different ways, which are detailed in the man page: 1) read in line by line from stdin with one line per -e option 2) from a plain text or compiled script file or 3) “interactively” from stdin. Using either option 1 or 3, the script must be properly “escaped” using appropriately placed backslashes in order to get the script past the shell. The exact details are in the man page, but here’s an example of “interactive” input:
$osascript < < EOF >tell application “iTunes”
and exactly the same script, but using the -e option: $osascript -e ‘tell application “iTunes”‘ -e ‘play’ -e ‘end tell’
Useful for making shell scripts for visually-impaired people (or playing practical jokes over SSH), this little utility utilises the system-wide speech synthesis manager to convert text to speech. Simply $say Hello will speak the text “Hello” using the default voice set in System Preferences. Other voices can be specified using the -v option followed by a name of a voice (which are the same as the names in System Preferences).
Input can also be from a text file, using the -f option followed by a file name and, more interestingly, the sounds can be output to an AIFF file using the -o option followed by a file name. As with osascript, say can be used in “interactive” mode by running it with no options. Text entered on stdin will then be spoken after every line return.
This brilliant and powerful tool replicates the functionality found in the Image Events Applescript suite. In terms of editing, it allows images to be cropped, rotated, flipped, resampled and padded to a certain size. In addition, sips can change the format of an image to or from any of the following formats: jpeg, tiff, png, gif, jp2, pict, bmp, qtif, psd, sgi, tga. Finally, functions are also provided for reading and editing EXIF data and working with ICC profiles. As per usual, the man page goes into great detail about the various options, but here are a few select examples of how to use sips:
There are numerous other uses for sips, but I think the above is a reasonable summary of the most useful features.
This is a CLI tool that exposes all of the standard OS X screenshot functionality. It can be used over SSH, in conjunction with SFTP or even Apache, as a kind of poor man’s VNC. Rather than having a user describe a problem over the phone or by IM, a quick $screencapture -m -tjpeg /Library/WebServer/Documents/screenshot.jpg takes a screen capture of the main screen (-m) as a JPEG (-tjpeg) and saves it in the default Apache serving location, allowing the image to be accessed over the internet at http://22.214.171.124/screenshot.jpg, for example.
As with the standard manifold command-shift-(control)-3/4 key combinations for taking screenshots,screencapture provides flags for interactive screen capture (-i or -iW for window selection mode), sending the image to the clipboard (-c) rather than a file, capturing the mouse cursor (-C) and turning off the camera sound (-x) for stealthily finding out the current user’s up to. A clever little tool indeed. screencapture, however, doesn’t allow for timed screenshots as found in Preview.app or Grab, but this functionality is easily replicated at the command line as follows: $sleep 5; screencapture -m screenshot.png &, which waits 5 seconds before taking a capture of the main screen.
As the name suggests, this is the CLI equivalent of “Software Update…” in the Apple menu and offers similar functionality. It must, for obvious reasons, be run as root. $sudo softwareupdate -l will give a list of all available updates for the current system including, crucially, labels for all the updates which have no spaces in their names to negate the need for awkward escaping when using other flags with softwareupdate. These other flags include -d (to download all available updates), -i (to install all or, if a label is specified, a specific update) –ignore <label> to ignore certain updates and –reset-ignored which, as you might expect, makes all applicable updates visible again on the next use of $sudo softwareupdate -l.
So that sums up the second round-up of interesting CLI tools in OS X. I think in the next installment, I’ll take a look at some more developer-targeted tools like otool, lipo and launchctl…