If you use a column-view Finder window, and prefer to use keyboard navigation, here’s a trick you may not be aware of—even though this dates back to the original release of Mac OS X. If I hadn’t started the Mac OS X Hints site, I doubt I would’ve known this…
To drill down into Finder folders via the keyboard, you use the Right (down) and Left (up) Arrow keys-don’t worry, that’s not the tip, because that’s totally completely obvious. The tip is this: After navigating into a given subfolder (and optionally selecting an item in that folder), the Shift-Tab key combo will navigate back up, but leave your “path” to the subfolder visible. Think of this like a “breadcrumb” trail that shows your navigation. (By comparison, if you use the Left Arrow, Finder “closes” each folder as you exit it, leaving you with nothing selected once you reach the top.)
One you’ve used Shift-Tab to navigate all the way back out, pressing Tab will navigate back down the highlighted path. Alternatively, pressing the Right Arrow key will jump immediately to the rightmost-selected item. Here’s how that all looks in action—first is the normal arrow key navigation, then navigation using Shift-Tab and Tab.
You may not need/want the breadcrumb path all the time, but when you do, just remember to Shift-Tab your way out of the current folder. Using the arrow keys and the Tab/Shift-Tab keys together provides two complementary methods to navigate your column-view Finder windows.
After getting this working, though, I wondered if it’d be possible to keep my backups from the first day of each month, even while clearing out the other dates. After some digging in the rsync man page, and testing in Terminal, it appears it’s possible, with some help from regex.
My backup folders are named with a trailing date and time stamp, like this:
The new bits, -not -regex ".*-01_.*" basically say “find only files that do not contain anything surrounding a string that is ‘hyphen 01 underscore.’ And because only backups made on the first of the month will contain that pattern, they’re the only ones that will be left out of the purge.
This may be of interest to maybe two people out there; I’m documenting it so I remember how it works!
With my Time Machine-like rsync backups running well, I decided it was time to migrate over the cleanup portion of my old script—namely, the bit that removes older backups. Soon after I added this bit to my new script, though, I had a surprise: All of my backups, save the most recent, vanished.
In investigating why this happened, I stumbled across two rsync/macOS behaviors that I wasn’t aware of…and if you’re using rsync for backup, they may be of interest to you, too.
If you have certain System Preferences panels that you access a lot, and you’re a Dock person (as opposed to a ⌘-Space and type person), here’s a little timesaver: You can add any System Preferences panel directly to your Dock. You can’t add it to the left side, as the individual panels aren’t applications. But they are documents, so you can add them to the right side of the dock—just drag and drop from Finder.
You’ll find the System-provided panels in /System/Library/PreferencePanes; third-party panels may appear in either your user’s Library/PreferencePanes folder, or the top-level /Library/PreferencePanes folder. Find the one(s) you’d like in your Dock, then just drag and drop.
You can, of course, keep System Preferences itself in your Dock, and then right-click to see a list of all preference panels. For those panels you access often, though, this method is much quicker.
I wanted to install Linux on a hard drive in Frankenmac, as Clover is a multi-boot utility—it lets you choose from any OS it sees during power up. (I’ll add Windows, too, eventually.) To do this, you need to get Linux onto a USB stick. I’ve done this in the past, and my vague recollection of the process was download the ISO, convert to an image file, write image file to USB stick. However, as it’d been a few years, I went searching for references to make sure I had all the commands correct.
I found a lot of pages with a general summary of the process, and few with the specific steps. I tried one of those, but my USB stick didn’t work. The other specific pages contained the same basic process, so I was stuck. Until I found this page, which contained a critical step I was missing: Formatting the USB stick before copying the image file.
For future reference, here’s the precise process to follow if you want to burn an ISO file onto a USB stick…
In yesterday’s tip, See sensor stats in Terminal, I implied that installation of the iStats ruby gem was a simple one-line command. As a commenter pointed out, that’s only true if you already have the prerequisites installed. The prerequisites in this case are the Xcode command line tools. Thankfully, you can install those without installing the full 5GB Xcode development environment.
Here’s how to install the command line tools. Open Terminal, paste the following line, and press Return:
When you hit Return, you’ll see a single line in response to your command:
$ xcode-select --install
xcode-select: note: install requested for command line developer tools
At this point, macOS will pop up a dialog, which is somewhat surprising as you’re working in the decidedly non-GUI Terminal:
Do not click Get Xcode, unless you want to wait while 5GB of data downloads and installs on your Mac. Instead, click the Install button, which will display an onscreen license agreement. Click Agree, then let the install finish—it’ll only take a couple of minutes.
If you’re curious as to what just happened, the installer created a folder structure in the top-level Library folder (/Library > Developer > CommandLineTools), and installed a slew of programs in the usr folder within the CommandLineTools folder.
Someone—perhaps it was Kirk—pointed me at this nifty Ruby gem to read and display your Mac’s sensors in Terminal: iStats — not to be confused with iStat Menus, a GUI tool that does similar things.
Installation is sinmple, via sudo gem install iStats. After a few minutes, iStats will be ready to use. In its simplest form, call istats by itself with no parameters. Normally I’d list the Terminal output here, but istats (by default, can be disabled) presents informatiomn with neat little inline bar graphs, so here’s a screenshot:
This tool is especially useful on a laptop, as it provides an easy-to-read battery summary.
That particular format is the one I use most often, with the full date followed by the hours and minutes in 24 hour format: 2017-04-12_2315, for example. I use this one so that filenames wind up sorted by date order in Finder views.
Once I move beyond that format, though, the vagaries of date string formatting leave me dazed. Enter strftime.net, where you can build any date string you like using a point-and-click editor with real-time previews:
And that’s all there is to it. Note that you may need a newer version of rsync than what comes with macOS now (2.6.9)—I use version 3.1.2 from Homebrew, so I can’t say for sure that this script works with the stock version.
I’ve only been using this for a couple weeks, but it’s working well for me so far.
In the shell script I use to back up my web sites (I really should update that, they’re much different now), I include a line that trims the backup folder of older compressed backups of the actual WordPress databases. That line used to look like this:
If no units are specified, this primary evaluates to true if the difference between the time of last change of file status information and the time find was started, rounded up to the next full 24-hour period, is n 24-hour periods.
If units are specified, this primary evaluates to true if the difference between the time of last change of file status information and the time find was started is exactly n units. Please refer to the -atime primary description for information on supported time units.
To make find do what I wanted it to do, I just needed to change +5 to +5d. Simple enough…but while figuring this out, I stumbled across this page, which has an alternative solution with more flexibility:
The mmin parameter is much more precise than ctime:
True if the difference between the file last modification time and the time find was started, rounded up to the next full minute, is n minutes.
By using mmin, I can be really precise. As shown, 60*24*5 gets me the same five-day interval as ctime +5d. (And yes, I could have used 7200 instead of 60*24*5, but I find it clearer to leave it in its expanded form.)
But I could instead delete backups that were older than 3.25 days (60*24*3.25 or 5040), or for any other arbitrary time period. I like the flexibility this offers over ctime, so I’ve switched my script over to this form.