tmutil: How to find hidden arguments

tmutil is a handy tool to control Time Machine backups from the command line. I think Apple added it in Lion, but I don’t have a pre-Lion system to verify that.

“man tmutil” and “tmutil” (with no arguments) print helpful usage information, but I was surprised that there were no commands to see what destination Time Machine was currently using. I also couldn’t find a command to tell me if Time Machine was currently running.

I figured tmutil must know that information, so I went looking for it.

The short version:

I found commands to do what I wanted:

tmutil destinationinfo

prints out where Time Machine will backup to.

And these two commands will print out different views of the Time Machine status:

tmutil status
tmutil currentphase

Of course, those commands are NOT documented by Apple, so they may not always work, but they seemed to work for me. YMMV, and they may set your computer on fire. No guarantees, blah blah blah. Taking advice from strangers on the internet is always a possible hazard to your health and happiness.

The long version:

Here’s how I found these undocumented/hidden commands.

First I figured out where the tmutil file lived:

$ which tmutil
/usr/bin/tmutil

Then I figured out what kind of file it was:

$ file /usr/bin/tmutil
/usr/bin/tmutil: Mach-O universal binary with 2 architectures
/usr/bin/tmutil (for architecture x86_64):    Mach-O 64-bit executable x86_64
/usr/bin/tmutil (for architecture i386):    Mach-O executable i386

This told me the tmutil file was an executable program, as opposed to a shell script. If tmutil was a shell script, I would have opened it in a text editor and looked through it for a list of commands. However, since tmutil is an executable program, it won’t yield its secrets to us quite as easily as a shell script.

To dig through executable programs and files you’ll need the “strings” command. It exists on every unix-y OS, including OS X. It describes itself in “man strings” like this:

find the printable strings in a object, or other binary, file

So I ran:

strings /usr/bin/tmutil > tmutil-strings.txt

I opened up tmutil-strings.txt in a text editor (MacVim is my editor of choice, thanks for asking) and looked for a command that I knew existed, “startbackup”, because usually all of the supported command line options for a program will be near each other in the strings output. Here’s what I saw near the “startbackup” text:

/SourceCache/TimeMachineTools/TimeMachineTools-41.3/tmutil/tmutil_common.m
EnumerateModulesWithBlock
processor != NULL
help
enable
disable
startbackup   <<<--- this is what I was searching for
stopbackup
enablelocal
disablelocal
snapshot
delete
restore
compare
setdestination
destinationinfo
addexclusion
removeexclusion
isexcluded
inheritbackup
associatedisk
latestbackup
listbackups
machinedirectory
calculatedrift
uniquesize
verifybackups
currentphase
status
verifyadditions
quickcheckimage
GetVerbForVerbProc
proc != NULL

From this output I guessed that everything between “help” and “quickcheckimage” was a command line option. And it looks like perhaps the “destinationinfo” and “status” commands might be what I was looking for. I ran tmutil with those options and it looked good, case closed!

Here’s a complete list of commands that appeared in the “strings /usr/bin/tmutil” output that aren’t described in “man tmutil” or “tmutil”:

currentphase
destinationinfo
quickcheckimage
status
verifyadditions
verifybackups

I only tried “currentphase”, “destinationinfo”, and “status”. I’ll leave the rest up to curious readers.

So there you go: a brief walkthough of how to discover hidden and undocumented commands in an executable file. Of course, they may be hidden or undocumented for a reason: they may be buggy, unsupported, and have unforeseen and disastrous side effects. Use them at your own risk.

Mac apps I love: Caffeine

Caffeine, besides being one of my favorite ingredients in coffee, is a very lightweight app that keeps your Mac from dimming the screen, going to sleep, or starting the screensaver. It lives a quiet, satisfying life in your menu bar.

It’s perfect for when the Macbook is running on battery power I but don’t want the display to dim or go to sleep. I’m happy to leave my sleep/dim settings where they are and use Caffeine to keep my Mac awake.

Get it here: http://www.lightheadsw.com/caffeine/

Created by: Lighthead Software

Price: Free

Rating: 8 (1=never use it again, 10=first thing I install on a new computer)

Browser vs. Screen

From John Gruber (emphasis mine):

This is a fundamentally different vision for the coming decade than Google’s. In both cases, your data is in the cloud, and you can access it from anywhere with a network connection. But Google’s vision is about software you run in a web browser. Apple’s is about native apps you run on devices. Apple is as committed to native apps — on the desktop, tablet, and handheld — as it has ever been.

Google’s frame is the browser window. Apple’s frame is the screen. That’s what we’ll remember about today’s keynote ten years from now.

Google sells ads – search and the browser make sense for that market. Apple sells apps and devices – appstores and screens make sense for that market.

But doesn’t Google sell apps? And doesn’t Apple sell ads? Yes, but neither is very enthusiastic about it.

Gruber’s commentary is succinct and right on.

But what about Facebook? They sell ads, too, and Facebook’s frame is the browser window. But Facebook also has device-native apps, so their frame is the screen too.

Is Facebook going to get the best of both worlds? Their own ad revenue built on the backs of Google’s browser and Apple’s screens?

Two views on developing for Apple

Two different (opposing?) views on developing for the Apple ecosystem after today’s WWDC love-fest announcements:

The first is from Des Traynor’s post, “Playing their game”:

Apple always look out for their customers. They will always look to improve the experience. If that means adding software to their platform then so be it. If that software is in direct competition with your software, then so be it. If they roll out the software as a free update across all operating systems, leaving you for dead, then so be it.

Their ball. Their game. Their rules.

The second is from Marco Arment’s post, “What Safari’s Reading List means for Instapaper”:

So I’m tentatively optimistic. Our world changes quickly, especially on the cutting edge, and I really don’t know what’s going to happen. (Nobody does.) But the more potential scenarios I consider, the more likely it seems that Safari’s Reading List is either going to have no noticeable effect on Instapaper, or it will improve sales dramatically. Time will tell.

Des says you should stay the heck out of Apple’s way. If Apple might ever create it, you don’t want to be anywhere near it. If Apple decides to create the thing that you’ve created, they’ll kill your business. That makes sense.

(He also says that Apple looks out for their customers, which is almost, but not completely, incorrect. Apple looks out for their customers’ money, not their customers. It’s an important distinction.)

Marco says a rising tide lifts all boats. Apple’s new (free) product looks a lot like Marco’s existing (not free) product. Most people don’t know offline reading exists, so with Apple’s (free) publicity he hopes more people use an offline reader, and if he gets some new revenue he makes out okay. That makes sense too.

It sounds like Des thinks of Apple as powerful, childish tyrant. “You don’t want to be around when Apple loses its temper!”

Marco, however, seems to think of Apple as a morally neutral, unstoppable force of nature. “Good thing my boat is ready to sail, because we’re gonna get a lot of rain!”

Des and Marco each seem to be glad to be where they are, out of Apple’s direct path or in it.

Who is right? Apple: steer clear, or sail near?

And where are you? Out of Apple’s direct path (or Google’s, or Microsoft’s, or Salesforce’s, or Oracle’s…) or in it?