42 Astounding Scripts

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.

After I reinstalled Python 2, I also had to sort of reinstall the modules I needed as well. They were all still installed—the macOS installer didn’t throw them away—but the new install of Python 2 wasn’t finding them. The easiest way to fix this was to reinstall using pip.

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.

The text that calmaker will convert to an ics file.

The calendar in iCal.

Our high school class was very small, and so our high school reunions are small affairs. There were, for example, all of three events this year: a meet-and-greet, a dinner, and a lunch memorial. Even with such a small calendar, people still find a calendar file useful. But it’s not worth it to maintain the events in a calendar app (or, worse, create a calendar app). It’s easier just to keep the events in a simple text file.

So I made a Perl script to convert a simple text file of events into an iCalendar .ics file (Zip file, 10.7 KB). All it needs is a text file like this:

Very simple, and it’s obvious what this text means. In fact, if you open this in pretty much any modern text editor it will be formatted to highlight the important bits and to keep the separate events readable as separate events, because this is very simple Markdown text.

It’s also easy enough for a Perl script to convert to a .ics file.

The script is meant to take files created for human purposes, not computer purposes. Except for the title of the event, which must always come first (and always be preceded by two hash marks—that is, a Markdown level-2 headline), the order of information doesn’t matter. If the script doesn’t recognize a piece of information, it assumes that it’s part of the description. It completely ignores blank lines.

Use the script like this:

You can, of course, leave off the > minicon.ics to see the calendar file output to your Terminal screen.

The above event will be transformed into this: