42 Astounding Scripts

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.

The script gets the default filename from the first line of text—often, a Markdown headline.

One scripting option that is often overlooked on the Mac is the Finder toolbar. You can drag any application into the toolbar and it will then be available for clicking in any open Finder window—or for dragging and dropping files from an open Finder window onto the icon.

You can use this as a simple shortcut for items that would normally go under the Services menu, but it is especially useful for doing file-related things that don’t involve selecting files. There is no Services menu in Finder windows if nothing’s selected, but there is a toolbar.

I often have text in the clipboard that I want to save to a file. Very often I can see the folder I want that file in, open in the Finder. It’s annoying to see it right there and still have to go into Terminal to type pbpaste then into the Finder to drag the folder’s drag icon onto the Terminal then back into Terminal to press return. Or, in the case of iA Writer, to have to create the document, paste it in, rename it, drag the title bar icon of the correct location to the Move dialog¹ and then approve a move out of iCloud.

It would be a lot easier to have an icon in the Finder toolbar that would automatically dump clipboard text to a text file right there.

Often the text I’ve copied is a subset of a Markdown file. I’ve decided to make one collection of subthoughts in a post be, instead, the main thought in another post. It would be great if this hypothetical script could shift headlines to the left as necessary to make the top line be a top-level headline.

This script will do both of those tasks. It will prompt for a filename to save the clipboard text to, using the folder displayed in the current Finder window as the default location; and it will modify Markdown headlines, shifting them left appropriately to make the first paragraph be a top-level headline.

Open Script Editor on your Mac, and paste this in:

If you’re in the habit of transferring BASIC files from old computers to modern ones, you might discover strange characters in the files. They’re like a strange combination of text and binary. This is not a compiled program, however. In old-school BASIC, there was a difference between compilation and tokenization.

Compilation converted BASIC code to machine code, and compiled files would usually be stored with a file extension indicating that the code should be run directly rather than interpreted. Often, this extension was some variation of “.BIN”. On personal computers at least, compilation usually required third-party software to convert the BASIC statements to machine code.

Compiled programs were no longer BASIC. They were machine code. They couldn’t be listed or edited, at least in BASIC. It generally wasn’t possible to convert a compiled BASIC program back to the original BASIC. Like any other compiled software, if you wanted to recompile it you needed to keep the source code on hand.

The default BASIC on these personal computers were also not saved as straight ASCII. While saving to text was usually an option, the default for most BASICs was to tokenize programs both in memory and on disk. Tokenized files were usually saved with some variation of a .BAS file extension—often the very same extension used for straight ASCII, non-tokenized files. Whether a file was tokenized or non-tokenized was a bit in the directory listing for that file, not in the file itself.

Unlike compiling a program, which translates code statements and functions into machine language, a tokenized BASIC program is still BASIC. In the computers I used, tokenization was mostly, if not completely, a one-to-one translation of BASIC statement/function to the one- or two-byte token for that statement or function. This saved space on the system. Both disk space and RAM were limited on older personal computers. But it also made it much easier for the system to run the code on the fly—interpret it—and made the interpretation much faster.

Without tokenization, the difference between RESET and RESTORE in the Radio Shack Color Computer’s Extended Color BASIC, for example, won’t show up until comparing the fourth character. With tokenization, the difference shows up on comparing the first character—9D is the tokenization for RESET and 8F is the tokenization for RESTORE. Nor is there any reason to scan for the end of the statement or function. Each statement or function is at most two bytes.

Why? Where do these results come from?

On the Facebook CoCo group, someone recently asked about how I handled bit-checking in a question I asked on the Retrocomputing StackExchange about the joystick. They didn’t phrase it as a question about bits because they didn’t know that their question was about bits.

It’s not surprising. I don’t know about other computers, but Radio Shack tended to hide the bitwise nature of their 8-bit computers. The only BASIC functions that worked with bits were the logical operators AND, OR, and NOT¹, and they weren’t explained as bitwise. The first two are given a page in Getting Started with Extended Color BASIC, page 78, where they’re explained as if they’re the English words AND and OR.²

But these operators do not behave as the English words do, or as the explanation implies they do. Here’s an example. Go into your CoCo or an emulator such as Xroar, and type:

The first should give you 1 and the second should give you 7. In most modern programming languages, both would give you true, which, depending on the language, might be a boolean value or it might be the integer 1. It might even be one of the two values, the 3 or the 5, because of short-circuit evaluation.

How does Extended Color BASIC arrive by its return values? The answer is that AND and OR are bitwise operations. These are 8-bit computers. They describe their numbers in 8 bits³. Here are the bits for the numbers 3 and 5:

The logical operators do not compare bytes. They compare individual bits at matching bit locations. What AND does is, if the bit in the same location in each byte is 1, the bit in the resulting byte is 1. If either of the two bits are zero, the bit in the result for that location is zero. What OR does is return 1 if either of the bits are 1, and zero only if both bits are zero. So here’s what AND and OR do when comparing 3 and 5: