42 Astounding Scripts

A hundred and fifty-nine years ago, on November 18, 1861, Julia Ward Howe heard the song John Brown’s Body (lies a-mouldering in the grave) sung by Union troops in Upton’s Hill just outside of Washington, DC. She was inspired in the night with new lyrics to go along with the melody, literally couldn’t sleep until she put the lyrics to paper.

The rest is history. Her new lyrics over an old melody have uplifted generations of Americans from the soldiers of the Civil War through the mourners of John F. Kennedy.

But that is not the entire story. It’s common knowledge that the melody is from the older John Brown’s Body, and mostly common knowledge that the John Brown in the song was not the abolitionist John Brown who raided Harper’s Ferry back in 1859. People just naturally made the association after the raid.

What is not common knowledge is that Julia Ward Howe’s husband, Samuel Gridley Howe, was part of an abolitionist group that funded John Brown before the raid. How much they supported the raid is unknown, but it was very likely more than just chance inspiration that inspired Julia Ward Howe to take a melody from a song that had become linked with John Brown the abolitionist and marry it to a rousing anti-slavery battle hymn.

Assuming that the basics of the story are correct, Julia Ward Howe wrote the lyrics on November 18, 1861.¹ It was published in The Atlantic Monthly of February 1862. There were still three years of war to follow.

Many modern singers change the semi-final verse² from “let us die to make men free” to “let us live to make men free”. This originally struck me as wrong and as an affront to the incredible sacrifices of Union soldiers who gave their lives to end slavery in the United States.

I still prefer the original lyrics when I play it myself, but I’m coming around to not just accepting the change but supporting it. The original lyrics were written during a war, for soldiers and families of soldiers, to destroy an evil in pure form. Evil always returns, and not always in such an obvious manner. It is always a fight to keep men free, and evil often masks itself behind good intentions. Ronald Reagan famously said that we are always one generation away from slavery. Reagan and Abraham Lincoln both warned us that we must dedicate not only our dying but our living to keeping America a land of the free.

This, from Le Lutin in the July 1987 Rainbow, was a very annoying and time-consuming error to debug just using rcheck. It was obvious once brought into Xroar.

I’ve added a few new features to the rcheck script to make it more useful for typing in code from The Rainbow.

rcheck+ for macOS (Zip file, 2.4 KB)

The big, important change is that you can now specify the expected checksums on the command line. You can continue to use rcheck as before, and its behavior will not change. But if you add “:yyy” to a line number, it uses “yyy” as the expected checksum. For the final line, you can use simply “:yyy” or “yyy”.

When a checksum does not match the expected checksum, the script shows the difference. This is extremely helpful, because often merely knowing that the checksum is off by, say, 32, tells you what the likely problem is—a missing or extra space, or an incorrectly-cased letter. In fact, some errors are common enough that I’ve put a check for them in the script, as you can see in the example.

• The dash is right next to the equals on my keyboard, so that’s a common mistake.
• I’ve no idea why I often type 4 where I should type F, but I do.
• Ditto with typing a dash instead of an equals sign.
• Also, very commonly spaces will not be obvious and so will not be typed when they appear in a remark, especially when they appear (I suspect) at the end of a remark.
• Multiples of 32 can be the result of case issues, since the difference between upper and lower case characters is 32 in ASCII, or multiple missing/extra spaces.
• Every once in a while, not only can’t I find the supposed error, but the very next block of code is also off—by the inverse of the amount the previous block was off. I suspect that these are typos in the Rainbow checksum block.

There appears to be a bug in Safari 14, released for macOS Catalina on September 17, that makes Automator Quick Actions fail. This was extremely annoying. In the morning, I was able to write in markdown on blog comments, and in the afternoon I was not.

What happens is that, if you select text in a text field in Safari and choose to run a Quick Action from the Services menu, the Quick Action runs—if it does anything outside of Safari, you’ll see those actions happen—but it replaces the text with nothing rather than with the output of the service.

You can undo to get your raw text back.

This will affect any of the simple BBCode and HTML verification/conversion scripts in 42 Astounding Scripts that are meant to be run in forum posts or blog comments.

I’m writing this in Brave, so as to be able to use markdown while writing this post. I’ve verified that Google Chrome also still works with Quick Actions. Another option would be to write it in a text editor, run the conversion, and then copy and paste it into Safari.

I’ve also used pbpaste and pbcopy as a stopgap, since most of my Quick Actions are command-line scripts.

will take whatever text I just copied, run it through the “moronify” script, and then copy it to the clipboard so that I can manually paste it back into the text field it came from.

You can test that Quick Actions are half-working in Safari with a simple two-step “Hello, World” Quick Action. In Automator, create a new Quick Action. Make the first step a “Run Shell Script” that pipes the selected text to a text file on the Desktop.

Make the second step a “Get Specified Text” that produces the text “HELLO WORLD”.

A simple Quick Action in Automator to test Services in Safari.

Save it as “Hello, World”.

In any text editor or word processor, or an editable text field in any web browser other than Safari, selecting some text and running Hello, World from the Services menu will (a) write the selected text to the test file on the Desktop, and then (b) replace the selected text with “HELLO WORLD”. In Safari, it will write the text, but it will replace the selection with nothing.

As I wrote in the intro to 42 Astoundingly Useful Scripts and Automations for the Macintosh, there are two ways to get a script from the book to your computer. You can copy and paste it from the ebook. Or, you can go the traditional route and type it. It was old-school books with the latter sensibility that inspired me to write 42 Astounding Scripts, but I recognized that there were serious issues with that model, mainly to do with catching typos.

The best old-school computer magazine I read back in the day was The Rainbow for the TRS-80 Color Computer. Content-wise, it was very much like 80-Micro, which was the second-best: filled with amazingly cool BASIC programs, tutorials, and hardware projects. But unlike every other computer magazine that included BASIC code, The Rainbow had a program called rcheck and later, rcheck+.

Typos were inevitable typing in even short programs; the rcheck programs were designed to tell you not only that you had a typo but where the typo was, within a defined block of BASIC lines.

The rcheck+ program was so useful I’ve rewritten it in Perl, partly for the old-school community but mainly for myself.

It’s much more difficult to write something like that for modern scripting languages. BASIC had line numbers, which meant there were no blank lines. BASIC didn’t have indentation, which meant there was no worry about tabs vs. spaces. It didn’t even have tab characters in the code, at least on the Color Computer. And because memory was so tight, there weren’t very many spaces, either. There wasn’t even upper and lower case for the most part.

Still, I very seriously considered including a program like rcheck in 42 Astounding Scripts. Ultimately, I decided that it was likely to cause more problems than it solved. But last week I had the epiphany that an rcheck-style script could provide a literal line-by-line checksum, in fact a series of checksums that separate indentation from code, and that I could provide a zip file of those checksums.

Thus was check42 (Zip file, 107.4 KB) born. This script takes a script name as an argument and checks each line of that script against a corresponding line in a checksum file. It looks at (a) the level of indentation, (b) the number of characters in that line of code, (c) the sum of the ASCII values of those characters, and (d) an md5 hash of those characters.