January 12, 2017 at 7:50 PM by Dr. Drang
Whenever I write a post with a bit of shell coding in it, as I did last night, I get feedback showing me different ways of doing the same thing. In some cases this is helpful (I like learning new tricks, even if I decide not to use them), in some cases it isn’t (I don’t care how much better you think
zsh is, I don’t care how much better everyone else thinks
zsh is, it’s not enough better for me to bother with).
But while it’s nice to learn new things, unless I have the opportunity to use them often, they’re unlikely to stick with me. With little one-offs like last night’s commands for creating a year’s worth of monthly folders, efficiency isn’t measured by how much processor time is used, nor—and this is key—by the amount of typing I do. It’s measured by the total time and cognitive load used in thinking up how to solve the problem and then executing that solution. Usually the first solution that comes to mind, no matter how much typing is required, is the one that’s the most efficient when measured this way.
And what first comes to mind is unique to everyone. It’s based on everything you’ve seen and done in the past, what you’ve been working on most recently, and, by exclusion, all those many many things you never learned at all.
So when I need to generate a sequence of numbers, I think of using
jot. You might think the phrase “sequence of numbers” would lead me to think of
seq, and I confess that makes a lot of sense. But sense doesn’t enter into it. I learned
jot first, never really learned
seq (other than that it exists), so that’s what my brain goes to.
Of course, after you’ve solved your problem and have moved on, it can be helpful to look back on it and rethink it. If you come up with a simpler way to have done it, that little nugget may come back to you the next time you run into a similar problem.
And it’s even better if you can blog about it and get the opinions of others. After last night’s post, I had a brief Twitter conversation with Ryan M. He had some ideas that I’d never use—his idiosyncrasies aren’t mine, and he’s using a later version of
bash than I am—but he did remind me of the
-p option to
mkdir, which creates all the necessary intermediate directories to create the full path to the directory you want. With that, I realized that instead of
mkdir 2017 cd 2017 jot -w %02d 12 | xargs mkdir
I could have done it all with
jot -w 2017/%02d 12 | xargs mkdir -p
Come back next year to see if I still remember by then.
January 11, 2017 at 10:16 PM by Dr. Drang
I know it may seem as if I’m ready to throw in the towel on blogging—only 78 posts last year, and 15 of those were in January—but I’m not. Last year was very busy in both my professional and personal life, and my internet life had to take a back seat because of that. Also, there is the siren song of Twitter, which makes it so easy to say nearly what you want, especially if you’re willing to cheat and let your thoughts spill over into a second or third tweet.1 My goal for the year is to focus my tweeting on stupid jokes and replies to stupid jokes. Other stuff should go here, even when it’s relatively short.
Like this post would have been if I hadn’t done so much throat-clearing in the first paragraph.
To start the blogging year, I needed to make this year’s folder and monthly subfolders for the Markdown source files. This isn’t hard to do in the Finder, but it’s much more fun to do it in the Terminal. I go to the
source directory and issue these commands
mkdir 2017 cd 2017 jot -w %02d 12 | xargs mkdir
The “2017” in the second line doesn’t have to be typed out: Escape-period (⎋.) is the shortcut that enters the final item of the last line into the current line, much like typing ↑ enters entire previous command. And like ↑, typing ⎋. repeatedly works backward through your command history, entering the final item of each previous line in turn.
The interesting line, and the one that’s the most fun, is the third line, which populates the 2017 folder with subfolders for each month, like this:
jot command prints out the numbers from 1 to 12, with the
-w %02d switch formatting the single-digit numbers with a leading zero (the
-w switch uses the
printf formatting directives). Then the
xargs command takes that output and turns it into arguments for
mkdir, which creates all the subdirectories. Boom.
For many years, I thought
xargs was this really complicated command that only true Unix wizards could control. And while it can be used in complex ways, it is at heart a pretty simple utility. It’s sort of like a pipe, but instead of turning the standard output of one command into the standard input of another, it turns that standard output into a list of arguments for the second command. Once I understood that concept, it didn’t scare me anymore.
Strings of tweets longer than that are an abomination, worse than a textshot of your own words. When I see someone tweeting “Thread,” I stay away. ↩︎
December 24, 2016 at 5:26 PM by Dr. Drang
Earlier this afternoon, John Gruber tweeted out a scripting tip:
# This takes ~5 secs:
get computer name of (system info)
do shell script “scutil --get ComputerName”
— John Gruber (@gruber) Dec 24 2016 1:54 PM
I wasn’t surprised to see that a shell command is much faster than the equivalent AppleScript, but I was surprised to see a command I’ve never used before. And as I was looking up the uses of scutil, I realized I needed to improve my system for linking to Apple man pages.
As I mentioned back in May, over the years Apple has changed where it keeps its online man pages, messing up old links all over the internet. I was later told Apple was going to fix that with redirects, but in my experience older links still get you this:
To make it easy to link to the current man pages, I wrote this simple little Keyboard Maestro macro (which could just as easily be a TextExpander snippet):
The text in the Action is
%|% part tells Keyboard Maestro to put the cursor in that spot so I can type the name of the command.
I’ve been using this command for months and have always meant to share it but kept forgetting. Ironically,
scutil is a particularly poor command to use as an example of the macro’s value, because the macro assumes the man page is in Section 1, while
scutil is in Section 8.
What are the sections? They separate the commands by usage and were, I think, meant to makes searches go faster back when computers were much slower. MacOS gets its section divisions from BSD:
|3||Library functions, covering in particular the C standard library|
|4||Special files (usually devices, those found in /dev) and drivers|
|5||File formats and conventions|
|6||Games and screensavers|
|8||System administration commands and daemons|
Although most of the commands I look up are in Section 1, I’ve never been completely happy with this macro because it doesn’t always work. The section problem with
scutil got me thinking about ways to improve the macro.
Update 12/25/2016 7:04 AM
Once again, I started off by taking the easy way out and then decided to fix it. There are, in fact, many man page sections that aren’t simply numbered. There’s Section 1m, for example, which covers commands built from DTrace, like
iotop. The URL for its man page is
You can see how these multicharacter sections are handled: the first character is used in the
manx part before command name, and the whole section name is used in the suffix immediately after the section name.
This morning, before the rest of the family got up to open presents, I decided it would be easy to extend the macro to handle these multicharacter section names. These sections typically cover more obscure commands that I’m unlikely to link to, but it wasn’t that hard to change the macro to handle them, too.
Beyond this point, the post has been edited to reflect the further improved macro. Merry Christmas!
As best I can tell, there’s no way to tell the
man command to return just the section name of a man page, so I decided to extract it from the man page itself. The section name is given in parentheses in the header of the man page. For example:
SCUTIL(8) BSD System Manager's Manual SCUTIL(8)
The header is usually the second line (after a blank line), but sometimes it’s first. So what I needed was a pipeline to
- get the man page;
- delete any blank lines at the top; and
- return just the section name from the header.
After a few tries, I came up with this:
man scutil | sed -E '/^$/d' | sed -nE '1s/^[^(]+\(([^)]+)\).+$/\1/p'
The man page is piped to the first
sed command, which deletes all the blank lines. Deleting all the blank lines is overkill, but it was an easy command to write. The result is then piped to the second
sed command, which pulls out the first parenthesized string it encounters and prints out just that. I always use the
-E option for
sed because it provides “extended” regular expressions, instead of the ridiculous “basic” regular expressions that require backslashes in front of almost everything.
With that worked out, the improved Keyboard Maestro macro looks like this:
The brief pause at the top allows the deletion of the four-character trigger to occur even on my old 2010 MacBook Air. Then the user is prompted for the name of the command to look up:
With the name of the command in hand, the macro runs the pipeline shown above (using the name of the command just entered rather than
scutil) to get the section name. It then gets the first character of the section name, because we’ll need that to build the URL. Finally, it constructs the URL out of all these pieces and pastes it wherever you have the cursor. The macro works in a browser URL field as well as in a text document.
So thanks to John Gruber for showing me
scutil and reminding me that I needed to fix my man page link macro.
December 24, 2016 at 11:48 AM by Dr. Drang
It’s been nearly two weeks since I left you hanging midway through the thrilling tale of the iPhone 6S battery replacements for my wife and me. In our last installment, we learned that my replacement went well, but since I hadn’t been having the sudden shutdown problem, it was my wife’s experience that would be more interesting. She’d been having the sudden shutdowns for a couple of weeks.
In short, she’s had a new battery for about 10 days now, and the shutdown problems have disappeared. The battery replacement solved the problem.
As I said in the last post, our local Apple Store didn’t have replacement batteries in stock on the Sunday when we first went in. They arrived on the following Thursday, which, as luck would have it, was when my wife was leaving town for a few days. Because the stores will only hold the battery for you for 5 days, I told the Apple Genius about my wife’s situation when I went in to get my replacement and asked if they could start her 5-day clock on the following Monday when she’d be back in town. No problem, I was told, and the Genius typed something in on her iPad.
But on Tuesday of the following week, the day after her 5-day clock was supposed to start, my wife got a voice mail message saying her 5 days were up and the battery would be given away to another customer if she didn’t come in. That’s one strike against the store.
Rather than call back to argue, she went in and handed over her phone. She was told the battery switch would be done in 2½ hours. This is longer than the 2 hours for my replacement but not bad. When she returned in 2 hours, it wasn’t ready. Give us another 20 minutes. She returned in 20 minutes and was sat at a table. After a while, she had the sense that they’d forgotten she was there and flagged down a store employee. The phone came out almost immediately. I’m not sure whether to call this one more strike or two.
I’ve never had bad service at an Apple Store before. They’re very busy, and service is never instant, but I understand that and have always been happy with how I’ve been treated. This, though, was a pile-on of what used to be considered very un-Apple-like behavior. Whatever system they’re using to track customers and service requests failed 2–3 times on the same request. Both my wife and I wrote about the problems on the customer feedback forms we got from the store.
Is this whining? If I were dealing with a discount store, I’d say yes. But expectations for Apple are higher, commensurate with the price you pay for their products and the quality image the company projects.