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.)
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.
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.
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.
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…
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 manysuchguides 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…