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

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:

processor != NULL
startbackup   <<<--- this is what I was searching for
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”:


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.

iOS5 makes the iPad 1 a slow and annoying experience

Marco says:

“The original iPad is nearly two years old, runs iOS 5 well, and will probably get a few more significant OS upgrades.” (link)

as a way to imply that Apple users are better cared for than Android users.

That might be true, but I disagree with Marco’s “iPad 1 runs well with iOS 5” statement.

I have an iPad 1 and it was snappy and responsive. I enjoyed using it. Note the past tense.

Then I upgraded to iOS 5.

Now apps crash far more often than with iOS 4, and *everything* is slower. The response to touchscreen interaction is so slow that I sometimes can’t tell if the iPad actually registered a touch; one or two seconds will go by and an app doesn’t appear to have seen the touch… and then it finally responds. Apps that never crashed before now crash at least once a day. Even Safari crashes on a daily basis, which you would think wouldn’t happen since that’s Apple’s own app.

As a tech geek you might think that I’m being too picky, and I might agree, except that my wife also agrees. She never complained with iOS4, but after a week with iOS5 she declared that it’s too slow to use. And she’s no cutting-edge speed demon; she’s perfectly happy on her 2006-era laptop.

I tried a couple of resets, reboots, and other potential solutions the Internets suggested, but nothing seems to help.

It looks to me like Apple crammed more functionality into iOS5 than the iPad 1 is able to comfortably handle. And I’m concerned that any further updates will do more of the same.

Just because Apple supports OS updates longer than Google/Samsung/etc. doesn’t mean that their devices are any better supported. Apple seems to have supported iOS5 on the iPad 1 in name only, not in spirit.

“Fixing” HipChat Crashes on Mac OS X Lion

In case this helps anyone else on the Internets and Googles out there:

If HipChat refuses to start for you on your Mac like this (“HipChat quit unexpectedly”):

"HipChat quit unexpectedly"

then you might be able to fix it by unchecking “Automatic graphics switching” in the Mac System Preference “Energy Saver” pane.

For some reason Adobe Air (the platform HipChat runs on) doesn’t like it when “Automatic graphics switching” is enabled.

After HipChat is running you can safely re-enable “Automatic graphics switching” to save energy when running on the battery.

Unfortunately right now you’ll have to disable “Automatic graphics switching” *every time* you want to start HipChat. Bummer. The HipChat folks and Adobe are all aware of this issue, hopefully we get a fix soon.

(I stumbled across this “fix” here on the Adobe forums:

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:

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?