Wandering Thoughts archives


The rc shell's nice feature for subdirectory searching of $PATH

I've used Byron Rakitzis's Unix reimplementation of Tom Duff's rc Plan 9 shell for a long time (for a variety of reasons). One of the ways that rc is different from standard Unix shells is that it has an unusual and surprisingly convenient additional feature in how it handles searching your $PATH.

In most Unix shells, if you type 'fred/barney' as a command name to execute, it's immediately interpreted as a relative path. For example, if you do:

$ fred/barney --help

this is the same as './fred/barney' and your shell will try to run something with that relative file name. This behavior matches the interpretation of this command name as a file name, since all file names that don't start with '/' are relative names.

In rc, relative names that don't start with './' or '../' are instead searched for on your $PATH, as the obvious combination of subdirectory (or subdirectories) and executable. If you do:

; fred/barney --help

then rc searches through your $PATH for something with a fred subdirectory with a barney in it. For example, it might wind up running $HOME/bin/fred/barney. See also this short description of rc's behavior.

This simple sounding feature turns out to be surprisingly useful. One way of putting it is that it lets you create namespaces for commands (with subdirectories being the namespaces); another way is that it lets you have "subcommands" of "commands" (where the "commands" are subdirectories and the subcommands are programs or shell scripts in it). In the rc approach, you would not have a "git" command that had dozens of subcommands and type 'git <subcommand>'; instead you would have a 'git' subdirectory somewhere in your $PATH and type 'git/<subcommand>'.

(In a version of rc that has command completion that includes these subdirectories (see here and here), this also creates a natural and general mechanism for completion of these 'subcommands', since they are regular executables.)

As far as I know, this nice little feature isn't widely available in other Unix shells. It's supported in zsh through the PATH_DIRS option, although apparently command completion can be wonky. I don't think Bash implements this directly with some option, but you could probably use Bash's 'command not found' hook function to do a version of this (maybe without command completion).

(I was inspired to write this entry by reading sd: my script directory (via), which basically implements this for normal Unix shells by using a cover program.)

PS: In rc, your $PATH is really your $path. But rc synchronizes the two environment variables for you so I've simplified the situation in this entry.

unix/RcSubdirectoryPATHSearch written at 23:57:04; Add Comment

Why I'm mostly not a fan of coloured text (in terminals or elsewhere)

I recently read someone who was unhappy that in this day and age, a Linux distribution specifically chose not to enable text colours in its default shell dotfiles (obligatory source). They have a point about the general situation, but also I disagree with them in practice.

On the one hand, the hand of theory, it is 2021. Our environments have been capable of coloured text for a long time (even if some people chose to turn it off), but here we often are, not using that capability. In many ways the default text environment is still single colour, with use of colours as the exception instead of the normality. In one sense, we really should have good use of colour in text by now.

On the other hand, the hand of practice, I'm glad that colour isn't used much because much use of colour in text is terrible (along with use of other methods of text emphasis). One technical reason for this is that many colour schemes for text assume a single specific foreground and background colour but don't (and often can't) force that, and wind up looking terrible in other environments. I run into this relatively frequently because I more or less require black text on white for readability, while many people prefer white text on black (what is often called "dark mode" these days).

A broader reason is that most colour schemes are not designed with a focus on contrast, readability, and communication (I think they're often not systematically designed at all). Instead they are all too often a combination of what looks good and matches the tastes of their creators, mingled with what has become traditional. This is colour for colour's sake, not colour for readability, information content, or clear communication.

(Even when some consideration has been put in for what the colours will communicate or emphasize, it often contains embedded value judgments, such as showing code comments in a colour that de-emphasizes them.)

There are probably text colour schemes out there that have been designed with a careful focus on contrast, readability, and HCI in general (and an awareness of the various sorts of colour blindness). But even in 2021, those colour schemes are a relative rarity. In practice, most colour schemes are various forms of fruit salad.

(This lack of careful design is not surprising. HCI-based design is hard work that requires uncommon skills, and also dedication and resources for things like user testing.)

I would probably like good colour schemes if they were common. Unfortunately, all too often my choices are either bad colour schemes or monochrome, and so I vastly prefer monochrome for the obvious reasons. In monochrome, all the text may blend together but at least I can read it.

tech/TextColoursWhyNot written at 00:24:34; Add Comment

Page tools: See As Normal.
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.