Archive for the ‘unix’ Category

Who Got Perl from Me?

August 2, 2019

Unexpectedly, I made the de-facto distribution tar files for source code releases of the Perl programming language for a year or two in the early 1990s. Up until sometime in the Perl 4 release cycle, its author Larry Wall distributed Perl by posting a set of several dozen shar (shell archive) files on the Usenet group comp.sources.unix or comp.sources.misc, so people using dialup modems could download them without having to restart if the phone disconnected. In between major releases, he posted patches which were much smaller than a full distribution.

I was volunteering for the GNU project, which distributed Perl as a courtesy since it was popular free software that used the GNU license. The GNU FTP site distributed source code in compressed tar files, so each time Larry released a new Perl version, I downloaded the shars and created a single tar file which I uploaded to prep. Dozens of organizations mirrored the GNU FTP server and did their own redistribution, so it was amusing to notice that most of the Perl 3 tar files out there had my user name in them if you did a tar -tvf to list them. They seem to have fallen off the Internet by now, as the last Perl 4 release is the oldest version that’s easy to find.

I finally stopped when Larry started making tar files of Perl releases himself. Larry last posted Perl 4 patch shars to comp.sources.misc in June 1992. I don’t remember whether he started making tar files concurrently, or only after he stopped posting the shars.


Why Do Long Options Start with Two Dashes?

August 2, 2019

Around 1990, Richard Stallman (RMS) and I were writing the GNU C library getopt() and he wanted to extend it to support long (multi-character) option names for user-friendliness. He considered Unix inferior in this regard to other operating systems such as TOPS-20 which supported long options (that could be abbreviated). He wanted GNU to be better than Unix while still compatible. There were a few programs that ran on Unix systems and used long option names starting with either - or no prefix at all, such as find, but those syntaxes were not compatible with Unix getopt() and were parsed by ad-hoc code.

Long options needed a prefix that wouldn’t clash with the Unix conventions, so programs could support both types of options without ambiguity. Richard chose +, since logically if - (for a small number mathematically) is for short options then + would be for long options, and it’s no additional typing. We created an extended interface called getopt_long() to support specifying long options.

But when the IEEE POSIX shell and utilities standard was published in 1992, the + syntax was disallowed. GNU developers discussed what to do over email. We considered -+ as the long options prefix, but that was hard to type, so we settled on --, which wouldn’t violate POSIX or Unix compatibility and wasn’t hard to type.

For a few months, GNU getopt() supported both + and -- to allow time for people to transition their scripts. I’m pretty sure support for + during that transition could be disabled by setting the environment variable POSIX_ME_HARDER (RMS’s exasperation with standards showing there), later changed to the more polite POSIXLY_CORRECT, which also disables recognizing options intermixed with positional arguments.

Because GNU software was popular and the solution was logical, everyone else adopted the -- prefix and implemented variations of it in their own argument parsers. Perl was probably one of the first.

From Novice to Master, and Back Again

January 14, 2013

In 1985, I was a freshman at St. Olaf College in Minnesota. The college had a VAX 11/780 running 4.2BSD and a PDP-11/70 running v7 with some Berkeley and local code hacked in. It was my first experience with multi-user systems other than dialing into an MS-DOS BBS or two.

The college’s Academic Computing Center had printouts of the 4.2BSD manuals, plus some home-grown documentation, available for sale so students could learn how to use UNIX. One week I sat in the Science Center terminal room and started going through the alphabetical list of the commands available on the VAX, trying each one and reading its man page to learn what it did.

Eventually I got to “su”. “Become the super-user”? What’s that? Does it involve wearing a cape? Sounds interesting, so I tried it. To my disappointment, it just asked for a password, and wouldn’t do anything.

Shortly thereafter, someone came running into the room and asked, “Are you David MacKenzie? Did you just run ‘su’?” “Yeah… what does it do?” “Uh, don’t do that.” My failed “su” attempt had been logged on the system console and one of the sysadmins was worried about an attempted breakin.

Within a year, I did have root access on the VAX, as I learned enough to be hired as a student system programmer. I contributed to upgrading the machine to 4.3BSD when that was released.

Recently I was working on a CentOS Linux virtual machine and needed to look up the command-line options to “su”. I had worked for the past several years mostly on Macs where “sudo” is preferred, so my “su” skills were rusty. I ran “man su” and got the information I needed. Then at the bottom of the screen I sheepishly read “Written by David MacKenzie.”

In the 1990s, while filling in gaps in the GNU toolset, I wrote the GNU “su”, and I had forgotten about it. It’s still what Red Hat and other distributions are shipping.

At least I know what it does now.