About Astounding Scripts

I apologize for putting this off for so long; I’ve been expecting to see more changes that need to be made in scripts after upgrading to Ventura, because this is hardly worth a post. But it could be very annoying if you’re relying on padmath.

Padmath stopped working after upgrading to Ventura. I noticed that very quickly—it’s one of my most commonly-used Services. But it’s a simple fix. The version of bc on Ventura now has an abs function. This means that abs is now a reserved word, and cannot be used to create a custom function.

Since the custom function was just a means of adding an abs function anyway, delete the lines that define the custom abs function and padmath will start working again.

I haven’t yet noticed any other issues with using the scripts under Ventura.

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.

Just a quick note: I upgraded to Big Sur a few months ago. The scripts appear to need no changes from the current edition of the book.

I may still publish a new edition of the book, but the only change would be the boilerplate that mentions what operating system the book is for. Instead of referencing “macOS Catalina” on the indicia page, it would reference “macOS Big Sur”. Everything else would remain the same.

And I may not do this, because of the ever-present potential of meeting new bugs in either the Smashwords or Amazon review process when uploading a new file. In programming, “if it works, don’t fix it” is often very good advice, especially when dealing with what are essentially black boxes where it is difficult to know how the input affect the output.

In fact, having written that, I have convinced myself to not upload a new version with just the boilerplate changed. I’ll save that effort for when Monterey comes out.

A quick note that I’ve just got the update of Safari from 14.0.2 to 14.0.3, and Quick Actions that replace text inside of Safari text fields are now working again.

I’ve removed the “Copy to Clipboard” workaround (so that I no longer erase text previously copied to the clipboard) from the three scripts that I use most often in Safari, and am having no problem editing and modifying text inside of text fields.

I was getting worried that this was a permanent change, and am very happy that it turned out to really be a bug and not deliberate. It’s more than a little disappointing that the bug didn’t get caught before it went out—as both a programmer and a writer, I find Services in Safari text fields extraordinarily useful. I use it often enough that I noticed it within a few hours of performing the update. In fact, I’m using it right now. When I’m done writing this short note, I’ll run my Markdown to Blog HTML service on the text to convert simplified Markdown to the simplified HTML I use for posting.

I don’t use all of my Services scripts on a daily basis, but I do use at least one of them every day.

This is with Safari on Catalina 10.15.7. I should be updating to Big Sur soon, for varying definitions of “soon”, but would expect (or hope) that it’s either also been fixed or was never a problem on Big Sur.