42 Astounding Scripts

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.

Two menu screens from MENU.BAS: some of my favorite games from The Rainbow, and some of my favorite text-based games typed in from various books.

For the true retro experience, you should, of course, access files from the command line, typing DIR to see the disk, interpreting the very abbreviated filenames, and then using RUN or LOADM to start the program. For the full retro experience, everything should be on cassette tape!

But your friends may enjoy the retro gaming experience without having any idea how to start up the games. You could, of course, put a coffee-stained sheet with helpful command-line hints next to the computer. Or, you could use this BASIC program, that leverages Darren Atkinson’s CoCo SDC floppy disk emulator to provide a simple interface to your favorite games (Zip file, 8.4 KB) saved on both the SDC’s flash slots and on .DSK disk files.

You can have as many screens as you want. The more screens, the longer it will take to load, and the more screens you (or your friends) will have to cycle through to see everything. I meant this as an easy means of showing off my favorite games; it is not meant as a comprehensive listing of everything. For a more complex file browser, see Guillaume Major’s SDC Explorer.

As written, MENU.BAS requires the SDC, but it should be able to be modified to use other solutions that store programs in ways that they can be accessed from a BASIC program.

The program attempts to respond to whatever the user might do to choose a game. If they pick up one of the joysticks, it will start following that joystick; if they use the up or down arrow keys, it will respond to them; SHIFT-up and SHIFT-down will move to the top and bottom, respectively. If they type the number corresponding to a game, the pointer will jump directly to that game.