As I’ve written about in the past, I use Don Melton’s video transcoding tools to rip Blu-Ray discs. I also use Homebrew to install some of the transcode video dependencies, as well as other Unix tools.
Keeping these tools current isn’t overly difficult; it only requires a few commands in Terminal:
$ brew update
$ brew upgrade
$ sudo gem update video_transcoding
My problem is that I often forget to do this, because—unlike most GUI Mac apps and the Mac App Store—there’s no built-in “hey, there’s an update!” system. Suddenly, two months and many revisions later, I finally remember (usually when I see a tweet about a new version of something.) So I thought I’d try to write my own simple update reminder.
I didn’t really want a scheduled task, like a launchd agent—it’s not like these tools need to stay current on a daily basis. (And one of them needs to run with admin privileges, which complicates things.) I just wanted something that would remind me if it’d been a while since I last checked for updates, and then install the updates if I wanted it to do so.
After mulling it over, I came up with a script that runs each time I open a Terminal window (which I do daily). The referenced script looks at the date on a check file, and asks me if I’d like to check for updates if that date is more than a week older than today’s date. This is perfect for my needs: The reminder is automatic, but I can choose when to install the updates based on what I’m doing at the time. If it’s been under a week since I last checked, nothing at all is different about my Terminal launch.
Read on for the script and implementation details. (Note: This is not written for a Terminal beginner, as it assumes some knowledge about how the shell works in macOS.)
In my recent post A new set of Hubble deep space iMac retina desktops, I included a set of auto-cropped 5120×2880 desktops. In that post, I wrote:
These images were automatically cropped from the master image (after I cropped that; more detail on what I did is coming in a follow-up post), via ImageMagick.
So this would be that post: How to auto-crop huge images using ImageMagick. If you’re not familiar with it, ImageMagick is a set of command-line tools to manipulate images. There are a number of ways to install ImageMagick, but I used Homebrew (brew install imagemagick).
I use a ScanSnap ix500 scanner to scan a lot of paper into PDFs on my iMac. And thanks to the ScanSnap’s bundled optical character recognition (OCR), all of those scans are searchable via Spotlight. While the OCR may not be perfect, it’s generally more than good enough to find what I’m looking for.
However, I noticed that I had a number of PDFs that weren’t searchable—some electronic statements from credit cards and utility companies, and some older documents that predated my purchase of the ScanSnap, at least based on some tests with Spotlight.
But I wanted to know how many such PDFs I had, so I could run OCR on all of them, via the excellent PDFPen Pro app. (The Fujitsu’s software will only perform OCR on documents it scanned.) The question was how to find all such files, and then once found, how to most easily run them through PDFPen Pro’s OCR process.
In the end, I needed to install one set of Unix tools, and then write two small scripts—one shell script and one AppleScript. Of course, you’ll also need PDFPen (I don’t think Pro is required), or some other app that can perform OCR on PDF files.
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.
(Rather than starting from scratch, I’m just going to borrow this bit from my detailed instructions for installing the transcode-video tools, because the Xcode command line tools are required there, too.)
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.
Taking a break from the recent Frankenmac posts, here’s a little trick for creating “Time Machine like” backups of anything you’d care to back up1I don’t know how well this might work for Mac files, as opposed to Unix files. But Mac files can be saved to the real Time Machine.. In my case, it’s the HTML files off of my web sites, both personal and work. I used to simply back these up, but then realized it’d be better to have versions rather than totally overwriting the backup each day (which is what I had been doing).
Once you’ve got it set up and working, you’ll have a folder structure similar to the one at right, with one folder for each backup, and a “current” link that takes you to the newest backup.
I get zero credit for this one; my buddy James explained that he’d been using this method for a year without any troubles, and pointed me to this great guide that explains the process.
I used that guide and added the following to my backup script to create my own customized Time Machine for the files from here, robservatory.com:
/usr/local/bin/rsync -aP \
--link-dest=/path/to/quasi/TM_backup/current user@host:/path/to/files/on/server/ \
--exclude "errors.csv" \
--delete --delete-excluded \
rm -f /path/to/quasi/TM_backup/current
ln -s /path/to/quasi/TM_backup/back-$newtime /path/to/quasi/TM_backup/current
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.
Fair warning: Today’s tip is over-the-top geeky.
After many years of not doing anything with web serving on my local Mac, I recently had a need to look at some mySQL/PHP-based web packages. While I could install these on robservatory as tests, I generally like to install things locally first, because I’ll install a handful of packages until I find the one I like. But it’d been so long, I didn’t have anything configured. (Remember when enabling Apache—i.e. web sharing—was a feature of the System Preferences’ Sharing panel? Ah, good times!)
I could have opted to use the built-in Apache, but I wanted something that I could more easily keep up to date, and that, if I chose, would be easy to remove. The good news is that Homebrew has packages available for Apache, PHP, and MySQL. Homebrew installs everything in its own directory tree, and adding and removing packages is simple—exactly the setup I wanted.
So in theory, installation was as easy as three brew tap commands. The reality, though, is that the installation is a bit more complex. OK, it’s a lot more complex. The good news is that, this being the age of the internet, help is but a search away. Or the advice of a friend away, which is what I used in this case.
A friend pointed me to this excellent installion guide that walks through the entire process, including installing two versions of PHP with the ability to switch between them on the fly.
It was this on-the-fly switching, though, that gave me troubles: I couldn’t get a site to load unless I specified “index.php” or “index.html” as part of the URL. (Apache is configured to grab those files automatically.) Solving that one took a bit of time…
Really long-time Unix users—as in mainframe-based Unix—are probably familiar with fortune. This silly little program grabs a random line from a collection of files holding quotes, sayings, jokes, etc. The Unix I used many decades ago would print an entry from fortune each time you started a new session. Here are some examples of what might greet me each time…
"It's a dog-eat-dog world out there, and I'm wearing Milkbone underware."
-- Norm, from _Cheers_
Mobius strippers never show you their back side.
All constants are variables.
Years ago, I had set up my Mac’s Terminal to output a fortune each time I opened a new session (window). At some point, though, I forgot to set it up on a new system, so it was gone. While fortune isn’t included in macOS’ Unix core by default, there are many ways to get it back, and it’s relatively simple to do so. Here’s one way…
This week, I made a rare appearance on a podcast other than our own The Committed podcast. I was a guest on The Next Track, a podcast about music and related things, hosted by iTunes AppleScript guru Doug Adams and my regular The Committed podcast cohost Kirk McElhearn.
We spent 30 minutes discussing ripping Blu-rays and DVDs to the Mac. I know, a real stretch topic for me, given I’ve never written about it!
Anyway, it was a fun show, so if you’d like to hear the voice behind these words, give it a listen.
An obvious interest area of mine is in ripping (and watching) movies using my Mac. I’ve talked about everything from installing the tools I use to how I rip to how to make sure I update the ripping tools. And though I’ve included some comparison pictures in the how-I-rip article, I’ve never done a deep dive into the various ripping options and how they compare on three key fronts:
- Speed: Faster is better; measured in minutes required to rip.
- Size: Smaller is better; measured in MB of drive space used.
- Quality: Higher is better; the closer the image quality is to the original, the better.
An ideal rip would be one that happens in seconds, saves into a 10KB file, and has quality matching the original. The reality, though, is far from the ideal. Ripping a movie involves making trade-offs between those three competing measures: Maximizing any one measure requires some sort of tradeoff with one or both of the other measures.
After ripping so many DVDs and Blu-rays over the years, I was curious about how HandBrake and Don Melton’s Video Transcoding tools handle those tradeoffs, so I decided to do some testing.
If you’d like to see what I discovered about ripping time, file sizes, and—with lots and lots of frame grabs—image quality, keep reading…
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…