Skip to content

macOS

View Unix man (help) pages in Preview

Today's tip goes well with yesterday's tip, which explained how to open any Finder item's folder in Terminal via Keyboard Maestro. Once in Terminal (and sometimes even when not in Terminal), I'll often want to check out the man page (help) for a given command.

You can do this directly in Terminal with man [name of command], of course, but then it opens on top of whatever you were working on, and you have to read it in Terminal. You could use another tab or window, but you'd still be reading in Terminal. There are times, too, when I'm writing about the Unix side of macOS, so I'm not even in Terminal, but still want to view a man page.

My solution to this problem is two different ways of doing the same thing: I open man pages as nicely-formatted PDFs in Preview. The method I use to get to that point depends on if I'm working in Terminal or not.

Update: I've modified the script and macro so that they properly handles two-argument man commands, such as man 3 printf.

In Terminal

Based on an old Mac OS X Hints tip, I created a very simple shell script:

The key to this little script is the -t option on the man command. From the (hehe) man man help file, here's what that does:

  -t     Use /usr/bin/groff -Tps -mandoc -c to format the manual page,
         passing the  output to stdout. The default  output format  of
         /usr/bin/groff -Tps -mandoc -c is  Postscript, refer  to  the
         manual  page  of /usr/bin/groff -Tps -mandoc -c for  ways  to 
         pick an alternate format.

In other words, the -t converts the help page into a PostScript file, which is something that Preview can easily open (which is just what the last line of the script does).

I named this script preman, because it uses Preview to open man pages. Once saved, I made it executable (chmod 755 preman), and I can then open any man page in Preview by typing, for instance, preman bash.

The output is nicely formatted, and by opening the man page in Preview, my Terminal session is uninterrupted. A quick adjustment with Moom, where I have a saved layout to position Preview and Terminal, and I can scan the man page while working in Terminal.

But what about when I'm not in Terminal? For that, I basically implement the same shell script, but with it set up to run within a Keyboard Maestro macro.

[continue reading…]



Open Terminal in selected Finder folder

Today's tip is just a re-implementation of a really old Mac OS X Hints AppleScript that lets you open a Terminal window with the working directory set to (i.e. cd'd into) the selected Finder folder.

This makes it really easy to jump into Terminal to do something from Finder, without having to do any mousing and minimal typing. What's new is that I've used Keyboard Maestro to turn the AppleScript into a macro that runs only in Finder, where it's available via hot key or menu bar trigger.

Here's the complete macro; download it now to look at and/or use as you wish. [Note: If you use iTerm2 instead of Terminal, you'll want to download this version instead. My good friend James, who runs Out of Control, did so. He tells me it works great.]

The name of the macro may look a bit odd—the 03) controls the sort order in the Keyboard Maestro menu bar item, and does not display when the menu is activated:

Keyboard Maestro also helpfully displays the assigned keyboard shortcut in the menu bar item, in case I've forgotten it.

[continue reading…]



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…]



Create an iTunes song info window using Keyboard Maestro

For those who aren't aware, Keyboard Maestro is a macro-creation tool, designed to help you automate routine tasks. But its powers let you do some really cool stuff, not all of which could be classified as automation. Such is the case with this project: Creating an iTunes song info pop-up window.

There are lots of apps out there—including Many Tricks own Butler—that can do this for you, and my Keyboard Maestro version is worse than most of those in many respects. However, I wanted to teach myself more about Keyboard Maestro, and this seemed like a good project with which to do so.

I use Buter's iTunes pop-up info window, which looks like this:

I wasn't really interested in the rating or volume controls (though they should be doable), but I wanted to see if I could get the album art and song info in a window via Keyboard Maestro. After some struggles, here's what I came up with in Keyboard Maestro:

My window is larger by design, so I can have somewhat more visible album art (aging eyes). And I can't decide on a background color or gradient, so it keeps changing—this was the look when I snapped the screenshot, but it's since changed again.

Read on if you'd like to know more about Keyboard Maestro, and how I used it to create this iTunes info window. (Note that this write-up assume some familiarity with Keyboard Maestro, though I try to explain each step in the process.)

[continue reading…]



A spreadsheet to track full-year running miles

2020 update: Everything here is out of date now, and has been replaced with my post on the 2020 version of the worksheet. In there you'll find a download link and full instructions. I'm leaving this article up only because it may be linked to from other places.

 
Update: I've created a much nicer run tracking workbook. Please use that version, as this one is out of date and is no longer maintained. I'm leaving it here because some of the "how to" bits are still applicable to the new version (and it's linked from that post), but I've removed the download link.

To help with my 2,016 miles in 2016 running project, I created an Excel workbook to track my progress. A couple people have asked for the workbook, so here it is…with some caveats and instructions.

First off, this was written for Excel 365, though it should work fine in recent versions of Excel. There is no Numbers version, there is no Google Sheets version…this is it. Start by downloading the worksheet and opening it in Excel.

The first thing you'll notice is that this is a really ugly workbook. The only thing I spent any time "prettifying" at all was the actual vs. goal chart, as that's the thing I tended to look at most often. The second thing you'll notice, depending on when you open the workbook, is that it appears nothing is working. The formulas will not work properly until January 1st, 2017.

[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…]



Remap non-modifiable keyboard shortcuts in any app

Ever run into a program that has some pre-defined keyboard shortcuts you don't like? In most cases, they're associated with a menu item, which means you can use macOS' built-in keyboard shortcuts function to fix them. (In System Preferences > Keyboard > Shortcuts > App Shortcuts.)

But what if the shortcut isn't associated with any menu item? Such is the case in Excel 365, which replaced a couple easy-to-type shortcuts (⌃I and ⌃K for inserting and deleting rows and columns) with much harder to type versions: ⇧⌃= and ⌃-. If there's no corresponding entry in the app's menus, it seems impossible to remap the shortcuts—unless the app itself offers that feature, which Excel did in prior versions.

The good news is that it is possible to remap any keyboard shortcut in any app, as long as you're willing to add one more program to the mix: Some sort of macro app. My example uses Keyboard Maestro, but any app that can send a key sequence in response to another key sequence will do the trick.

[continue reading…]



Apple Mail: Classic or modern layout?

To me, the modern view in Apple's Mail app is basically useless: I keep my Mail window at 1,020 pixels in width, because really, there's no need for it to take up more space than that. But at that width, the modern view's message preview is so tiny as to be basically worthless:

Obviously, that's classic view on the left and modern view on the right. With the classic view, I can read each email as soon as I select it in the list; with modern, I have to double-click a message to open in a new window, which is a waste of time and screen space. Modern only gets truly usable if I'm willing to make the window roughly 1,500 pixels in width.

So which layout do you use? Vote in the Twitter poll for the next day (well, 23 hours and counting).



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.