Skip to content

Terminal

Speed up your Mac via hidden prefs

Over my many years of running Mac OS X Hints, a huge number of defaults write hints were published.

For those who aren't aware, defaults write is a Terminal command that can be used to modify applications' settings. While you can use these commands to modify settings that are present in an app's Preferences panel, the more-common use of this command is to set non-visible (hidden) prefs that you won't find in the GUI.

Here are three of my favorites—three that not only perceptually but actually increase the speed of your interactions with your Mac. I still, to this day, execute these commands on any new Mac I set up.

Don't worry if you'd prefer to stay away from Terminal: I'll also show how to use the long-lived1The first reference to TinkerTool that I could find in the Mac OS X Hints archive was in March 2001. TinkerTool to set each of these options using a (relatively easy if crowded) GUI interface.

Tip 1: Change the sheet animation speed

Sheets are the attached windows that roll down from (and up into) the title bar of windows, such as the Save dialog in most macOS applications. The animation of these sheets, while visually appealing, does take some time.

Using this tip, you can basically eliminate the animation, greatly speeding the appearance and disappearance of sheets. Given how pervasive sheets are, this tip can save a lot of time each day. While the other tips offer actual speed improvements, they're nothing like the change you get by changing the sheet animation speed.

As a test, I opened and closed a Save sheet in TextEdit five times, both before and after applying this tip:

If you're scoring at home, that's a 47% reduction in the time required for just five cycles of a Save sheet.

[continue reading…]



Detailed instructions for installing the transcode-video tools

My method of ripping Blu-ray discs relies on Don Melton's video_transcoding tools. While these tools work great, they are command-line only (i.e. Terminal required). In my guide, I glossed over the installation bit, referring back to Don's basic guide. But for those new to Terminal, even Don's instructions may be too light on the details.

Hence this detailed installation guide for Don's video_transcoding tools. This guide walks a new user through every step of the process, hopefully getting even someone brand new to Terminal up and running with Don's tools. This will only be of interest if you're having trouble getting the video_transcoding tools installed. If that's you, though, hopefully this will be helpful.

The entire installation of the video_transcoding tool set and all its dependencies will take place in Terminal, which is the direct line to the Unix core of macOS. Open Terminal, which you'll find in /Applications > Utilities, and you'll be greeted by a window with some text; something like this:

This lovely interface is where you'll spend the next chunk of time, installing the video_transcoding tools, and all the programs it uses to get its work done.

Note that this guide is not a detailed introduction to Terminal or Unix. (There are many such guides on the net, and if you're interested, they're well worth reading.) This guide is focused solely on how to use Terminal to install the video_transcoding tools, not how to use Terminal on its own. So let's get started…

[continue reading…]



Revisiting ripping Blu-ray discs

A couple years back, I explained how I rip Blu-ray discs. A lot of time has passed, and I now use a slightly different procedure that results in much faster rips—with the caveat that the resulting file will be larger than the "slow" method, and is technically of slightly lower quality, though I can't visually distinguish the two.

The new method uses Don Melton's amazing video transcoding tools, a set of Unix programs that optimize video conversion in ways you cannot do (or easily do) in the Handbrake GUI. If you're new to Unix, but would still like to try these tools, I wrote a detailed set of instructions that should help get you up and running.

Using these Unix programs, you can rip a disc with various parameters, including one to optimize for speed (with good image quality) and another that tries to minimize the file size.

Here's a quick comparison of all three methods, as tested with the three-hour Hamlet Blu-ray. The 'Handbrake GUI' rip was done using, well, the Handbrake GUI as described in my original article. The second and third rows use Don's tools set to quick and veryquick modes, and the final row uses Don's tools set to optimize the file size.

MethodData CopiedConvert (hrs:mins)File Size
Handbrake GUI47.5GB3:526.8GB
transcode - quick40.1GB2:209.2GB
transcode - small40.1GB3:126.5GB

Tested on a late 2014 27" iMac with a 4GHz Core i7 and 24GB of RAM.

Using Don's tools in "quick" mode, you save time two ways: 7GB (15%) less data is copied to the hard drive, and the conversion process is over 90 minutes (38%) faster. The downside is that the final file size is 2.4GB (35%) larger. And that's what they call a tradeoff.

Using the "small" mode in Don's tools, you still save the 7GB (15%) of data copy, and still save 40 minutes (17%) over the original method. In addition, the file size is smaller than the Handbrake GUI version.

To summarize, regardless of whether you care more about file size or ripping speed, Don's tools provide an advantage over the Handbrake GUI: Either method is notably faster, and the small option generates smaller (or probably at worst, very similar) file sizes. (There's also a "big" option, if you don't mind somewhat larger files at a higher quality level.)

Keep reading to see some examples of the image quality of each method, and information on how to install and use Don's video transcoding tools.

[continue reading…]



The Finder’s GUI tax can be very expensive

Once a month, I download roughly 25 gzipped (.gz) files from Apple—these are our Mac App Store sales reports, with one file for each App Store region. I could have Safari expand these files (via the "Open 'safe' files after downloading' item in its preferences), but I prefer to leave that option unchecked. (Why? I often download archives that I want to leave archived, and I like to keep originals of many of the things I download).

If you work with lots of compressed files, you're probably familiar with what happens in Finder (see note) when you go to expand any semi-large number of files: The infamous Dancing Dialog™. It looks something like this…

[Note: Technically, this isn't Finder, it's Archive Utility doing the expansion. But this is the service that Apple provides to expand compressed files, and it's what 99% of macOS users will use. It can be changed via the Get Info dialog, but very few people will take that step. So to most users, it seems it's Finder handling the expansion. For ease of reference, I'm going to say it's Finder doing the expansion.]

Not only is this randomly-resizing dialog box visually annoying, it turns what should be a super-fast process into one that takes a ridiculous amount of time. The end result is that users think they have a slow machine—"it took over 12 seconds to expand 25 tiny little archives!"—when what they really have is a horrendously slow GUI interface to a super fast task.

Just how fast is the task, if the GUI doesn't get in the way? Thanks to the Unix core of macOS, we can answer that question using Terminal, the geeky front-end to the Unix core. The Unix command to expand .gz archives is gzip; so to expand all the .gz files in a folder (and keep the originals), you'd use this command in Terminal:

gzip -d -k *.gz

If you try this, you'll find out it's nearly instantaneous—press Return, and the files are expanded. Unix actually gives us a way to see exactly how fast it is, via the time command:

$ time gzip -d -k *.gz

real	0m0.013s
user	0m0.002s
sys	0m0.005s

This was for a set of 24 .gz archive files (on a solid state drive), and the real line in the output shows exactly how long it took to expand them all: 0.013 seconds. By comparison, I made a screen recording (with an onscreen stopwatch for timing) of Finder expanding the same 24 files; it took 12.8 seconds for all the dialog dancing to end. Think about that…

Expand 24 .gz filesFinder:
12.8 seconds		Terminal:
.013 seconds		Terminal is 984.6x faster than Finder

To put those results another way, if expansion time is linear, gzip could expand 23,631 files in the time Finder takes to expand 24 files. That's nuts!

(You can watch this video for a visual comparison of expanding the same set of files in Finder and Terminal.)

So it's not the computer that's slow, it's the GUI interface to the computer that (in this particular use case) is incredibly, horrendously slow. And there's no need for it—the separate individual progress bars, appearing and vanishing in under a second each, provide no useful feedback to the user. They just slow down the task.

Finder (née Archive Utility) should just execute the task without any visual feedback (though it should pop up a window if there are exceptions). If visual feedback is really required, a window with a single progress bar for the entire task would be OK, but would still slow operations down.

This is a great example of how an everyday task can make you think you have a slow computer, when what you really have is a fast computer with a slow interface element. Given how often we all deal with compressed files, it'd be nice to see Apple clean up this mess. Until they do, however, you can harness the power of Unix—even while in Finder—to speed up the task. Here's one way to do just that.



Total PDF pages in subfolders across folder structure

Last week, I wrote a script that ran through a folder structure and output the page count of every PDF in all folders and sub-folders, and also spit out a grand total.

While this worked well, what I really wanted was a script that just totaled PDF pages by sub-folder, without seeing all the file-by-file detail. After trying to retrofit the first script, I realized that was a waste of time, and started over from scratch.

The resulting script works just as I'd like it to, traversing a folder structure and showing PDF page counts by folder:

$ countpdfbydir
    47: ./_Legal
     2: ./_Medical-Dental
    15: ./_Medical-Dental/Kids
    11: ./_Medical-Dental/Marian
     2: ./_Medical-Dental/Rob
    35: ./_Personal Documents/Kids
    87: ./_Personal Documents/Marian
    28: ./_Personal Documents/Rob
    10: ./_Personal Documents/Rob/Golf
    12: ./_Personal Documents/Rob/Travel
-------------------------------------------------------------------
   249: Total PDF Pages

It took a few revisions, but I like this version; it even does some simplistic padding to keep the figures lined up in the output.

[continue reading…]



Goodbye cron task, hello launchd agent

On April 29th, 2005, Apple launched Mac OS X 10.4, aka Tiger. With Tiger came launchd, a new Unix-side job scheduling tool. launchd was intended to replace cron, the long-established (and quite cryptic) tool for such tasks.

And now, a mere nine-plus years later, I decided it was time to give up cron and move to launchd myself. Mr. Bleeding Edge, that's me! (Note: Unless you enjoy the Unix side of OS X and currently use cron to schedule tasks, this article won't be of much interest to you.)

Why now, after so long as a holdout? Primarily because I kept running into issues with cron tasks that needed to do things as "authorized me," such as mounting an encrypted disk image, or even just mounting a network share. Or my Mac would be asleep for a scheduled cron task, and it therefore wouldn't run. (launchd will queue any missed tasks to execute when the Mac reawakens.) Finally, my cron file was getting huge and unwieldy, and making simple changes was fraught with danger of breaking something.

So I dedicated a portion of a recent weekend to figuring out launchd, and migrating my cron tasks to this brave no-longer-at-all-new world. If you're still hanging on to cron, read on to see what I've learned about launchd—maybe it'll inspire you to move, too (or not).

[continue reading…]



Behind OS X’s modern face lies an aging collection of Unix tools

Note: This article has been heavily modified, as I was a total knucklehead and completely forgot about GPL v3—thanks to Geordie Korper for pointing it out in the comments. Basically, the cause of the aging Unix tools in OS X is GPL v3. I've updated the following table to include the license information. In every case but one (nano), GPL v3 is the license on the non-updated apps. So that's that…I'll leave this up, though, in case anyone's curious about this stuff.

As I covered recently, the version of bash that ships with OS X is quite old, and as such, is vulnerable to the recently-revealed bash security hole.

At some point, Apple will release an OS X update containing a patched version of bash. (Update released.)

So while Apple has patched bash, this version of the shell is simply ancient. Just how old is it? bash 3.2.53(1) is roughly seven years behind the current version, 4.3.25. Seven years is like, well, forever, in Internet time!

With that bash age gap in mind, I took at look at a number of common Unix apps—in both Mavericks and Yosemite—to see which versions were in use. Then I checked the same apps in MacPorts, a tool that makes it simple to install many Unix apps.

(MacPorts doesn't necessarily have the absolute latest version of every Unix app, but they do stay relatively current. For instance, they already have a patched version of bash that fixes the above vulnerability.)

The results were interesting, to say the least—many of the core Unix utilities in OS X are years and multiple versions behind their open source, er, sources. You can thank GPL v3 for that, as noted above (and covered in more detail below). But that still leaves the big question:

Does it matter?

That is, should we care that these tools aren't keeping up with their latest and (presumably) greatest versions? Is it a problem, or merely a statement that what we have works well enough for the majority of users? (For those who don't want to bother reading, my general opinion is no, it doesn't matter.)

[continue reading…]



My most-useful and least-used shell script

I have a large number of small shell scripts I've either written or collected over the years. Today I had the opportunity to use my favorite one—which is rare, as I only need it a couple times a year. But when I do need it, it's a wonderful little script.

It's also a very simple-minded script, as it does just one thing: it copies my public IP address to the clipboard and shows it in a pop-up message, as seen at right. OK, so that's two things, but they're very closely related.

Clearly this isn't something I need to do often, but when I do, the script changes this…

Switch to browser, open new tab, load the DynDNS check IP page, drag mouse to select IP address, press Command-C to copy, switch back to destination app, press Command-V to paste

…into this…

Press a key combo, wait about a second, then press Command-V

This is a big timesaver, obviously, and it makes the process about as easy as it could be.

I originally wrote this up for Mac OS X Hints a few years back, but thought I'd post it here (given the changes at Macworld, I'm not sure how long the hints site may be around). I've also modified it a bit, as I no longer use growlnotify for the onscreen display of the copied IP address.

You can read the original how-to at hints, or below, where I've posted the updated version that no longer uses growlnotify.

[continue reading…]