42 Astounding Scripts

The searchablePDF script creates PDFs that can be searched for text, using VisionKit to recognize the text and PDFDocument to create the PDFs.

I’ve recently acquired several old cooking pamphlets from companies such as Pet Milk, Borden, and so on, that are not yet available on the various Internet vintage cooking archives. I thought it would be nice to scan them myself, but a simple scan with a desktop scanner means they’re just images without the ability to find a particular recipe or ingredient in them.

Of course, the obvious thing to do is OCR them or even just retype them, and then reformat the text in a word processor and save that to PDF. I have done this with some texts, such as a Franklin Golden Syrup pamphlet and a Dominion Waffle Maker instruction manual.

But part of the thrill of collecting old cookbooks is seeing them in their original format with their original font and other formatting intact, warts and all. That’s what elicits “I remember that ad!” comments for the newer ones, and evokes a sense of history for all of them.

The Baker’s Dozen is a perfect example of that. The recipes are good—often great—but the overall effect would not be nearly as interesting without the mid-seventies photo and advertising style.

Swift, using PDFDocument and PDFPage can easily create a PDF from a series of images. Which I’ve never done because it’s almost as easy to just drag the series of images into an empty Preview document and save that as a PDF file.

Neither method of creating a PDF adds any ability to search them. It would be nice to both maintain the original formatting and add the ability to quickly navigate the document, either through a table of contents—something easily created using PDFDocument and PDFOutline in PDFKit—or by searching the text. Or, better yet, both.

Mouse is yellow: might want to plug it in when you’re done working today.

Keyboard yellow, mouse red: definitely plug it in when you’re done working.

The notification from macOS that a mouse battery is running low usually comes too late and at inopportune times. When it happens I soon need to stop everything or get a USB mouse somewhere.

What I usually end up doing is taking an unplanned break for a few minutes to get the mouse battery back up to a safe level, and then go back to work. And forget to plug it in for the long term when I’m done working.

It would be nice if I could customize the warning to happen earlier and be both obvious and unobtrusive when it does happen. GeekTool is perfect for obvious and unobtrusive. All I need is a script to generate the text to display and it will show up on the desktop, and only when it needs to.

If you always want to see the battery level of all battery-operated devices, use ~/bin/batteries. In GeekTool (or on the command line) you can add the --colors switch to display different levels with different colors; there is a warning level set to yellow, a critical level set to red, and anything else is green.

I’ve set the warnings to start at 30%, with critical explicitly at half that. I may change my mind later.

Using the actual color names—green, yellow, and red—requires that you have Term::ANSIColor installed. If you don’t, you can replace those codes with the actual color escape sequences:

If you only want to see the battery level of devices at or below the warning level, use ~/bin/batteries --warnings with or without --colors.

If you want to see devices that are charging, even if they’re above the warning level, add --wired to the command line.

I’m dividing my promised sequel to Future Snark into three parts, one each for three very smart views of a future that became our present. These are the anti-snark to that installment’s snark: Vannevar Bush (1945), Norbert Wiener (1954), and John G. Kemeny (1972). I was going to title it “Snark and Anti-Snark” to extend the Toffler joke^• further than it ought to go. But these installments are not snark about failed predictions. These are futurists whose predictions were accompanied by important insights into the nature of man and computer, what computerization and computerized communications mean for our culture, and what responsibilities we have as consumers and citizens within a computerized and networked society.

These authors understood the relationship between man and computer, before the personal computer existed. Their predictions were sometimes strange, but their vision of how that relationship should be handled embodied important truths we must not forget. Their views of our cybernetic future focus heavily on not just the interaction between user and machine but on the relationship between computerization and humanity in general.

Surviving the ongoing computer and communications revolution requires understanding that relationship.

I’m going to handle these authors in reverse order, starting with John G. Kemeny. Kemeny published Man and the Computer in 1972. If Kemeny’s name sounds familiar, you might recognize “Kemeny and Kurtz” as the developers of the BASIC programming language. Much of this book, while it wasn’t designed as such, is an explanation of why BASIC is what it is—a unique programming language unmatched even today as an interactive dialogue between the user and the computer. Unlike most programming languages—including BASIC itself on modern computers—Kemeny’s BASIC didn’t require creating programs in order to get the computer to do stuff. The same commands that could be entered into a computer program could be typed directly to the computer with an immediate response.

I finally upgraded to Monterey last month. There is only one major change as far as scripting goes, and it’s expected. Python 2 is gone, but Python 3 replaces it. Most other scripting languages remain.

Installing Python

If you want Python 2, you’ll need to install it yourself. If you’ve been using Python 3 via homebrew you can continue doing so; just be aware that there is now a default python3 in /usr/bin.

For your older scripts that still use Python 2, the easiest choice is the installer from Python.org. It doesn’t need to be managed through homebrew, because it’s never going to be updated again. Follow the directions to double-click the Install Certificates command as well, but do so from an administrative account.

If you are using homebrew for other things, you may find it easier to install Python 2 using homebrew as well; otherwise, other homebrew installations may try to install it anyway as a dependency. While there technically shouldn’t be any dependencies on Python 2, I found that this isn’t true for some older software. I’m not, apparently, the only one who is still using Python 2 for some important legacy apps.

Both methods of re-installing Python 2 will install it in /usr/local/bin, so that all you need to do to get your legacy Python scripts running is to replace #!/usr/bin/python with #!/usr/local/bin/python. If you were using /usr/bin/env python it will probably work without any change at all. But be aware that crontab will not necessarily import your environment, and so will not be able to find Python via env.

For that reason, I’ve just changed all /usr/bin/python and /usr/bin/env python to /usr/local/bin/python whenever I get the message that it can’t find an executable.

The transition from Python 2 to Python 3 is not seamless. Any command-line script that uses print, which is just about all of them, will fail.

The Ventura version of 42 Astounding Scripts will continue to use Python, though it will be Python 3.

Python modules

If you’re re-installing Python 2, you may also have to reinstall any modules, such as lxml, holidays, and loremipsum. If you’re switching from Python 2 to Python 3, you’ll definitely have to re-install them: the modules for each major version of Python are stored in different places.