Although not a CLI tool, I’ve just remembered how torturous to write puppeteer is to a non-native English speaker. I still double-check to see if I got it right.
I fail to come up with any harder words on the spot, though I know there are lots, but I find that puppeteer is spelled as it’s said: pup-pe-teer. Super easy, and I’m not native to the English language.
Well, I find “torturous” harder. Another one which makes me pause is “colleague”.
What is harder in a non-obvious way for many non-english keyboard users is the symbols. I use the german qwertz layout which means a slash, backslash, semicolon, and brackets require the shift key (or even Alt for backslash).
in many countries, torture is tortious
In retrospect, writing this non-native instead of a non-native would have made for a far less controversial statement.
I started using a US keyboard layout many years ago and just switch between them when I need the Swedish characters…
I’m using these in my .Xmodmap for German umlauts:
keysym a = a A adiaeresis Adiaeresis
keysym u = u U udiaeresis Udiaeresis
keysym o = o O odiaeresis Odiaeresis
Swedish characters probably have similar names.
That’s a solution, I guess, but the Swedish keyboard has other affordances, such as diaresis, acute and grave accents, euro-sign, etc. So it’s more convenient for me to stay in US layout mostly and just switch when I need to type the classic test phrase “räksmörgås é gött” (shrimp sandwich tastes good).
Same. The cultural empire won.
Very nice article with points I wish more people would consider — especially the “typeability” of commands.
I will however defend cfdisk. It’s a replacement for fdisk in the subset of use cases where fdisk‘s advanced features aren’t needed. Similar programs, though admittedly not named for their UI toolkits, are htop referring to its predecessor top, and of course vim mirroring its vi legacy. These short commands tend to almost become words in their own right (e.g. fsck), and I believe this “incremental” naming scheme is helpful to users in conveying a general sense of the program’s scope and purpose (e.g. “oh so it’s fdisk with curses”).
And hey, if a programmer is writing a new/different version of an existing tool but they’re struggling to name it in a clever or aesthetically pleasing way, both they and their users are probably better off with a name like cfdisk. The programmer gets to get on with things, and the users don’t have to get used to an outlandish or strange command name.
What about single-letter names? Why do they hardly ever get used? I almost never run w or X, but the theory would imply we use single-letter tools the most. But I hardly use any of them.
I like t better than ls once I’ve got it aliased to tree -alhDFQ -L 1 --dirsfirst "$@", and I have j set to jobs -l, but that’s it. It doesn’t really make sense, when I think about it. Does it break stuff? Never has for me.
tree -alhDFQ -L 1 --dirsfirst "$@"
Hats off to whoever helped replace sudo apt-get install .. with sudo apt install .., by the way.
sudo apt-get install ..
sudo apt install ..
Long years ago, w was extremely often used to see if your friends were on the same server so you could chat with them! Yes, that time is over, and it should be renamed to something like who which does nearly the same thing anyway.
did anyone else feel like this at the end of the article?
I’ve always enjoyed running StarCraft from commandline, or from some search box, where I need to type its name in order to run it ;)
Name your command after what it does. If it makes a directory, name it make directory. If it types a file, don’t name it dog, sheep or cat.
Ahem… “concatenate” is exactly what cat does. Pretty sensible abbreviation, really.
No, it’s a cute abbreviation, but not sensible. Why would you even need to abbreviate a command like that?
Because tab expansion is a modern luxury, and because screen space costs too, even nowadays. Not satisfied? OK… because verbosity becomes tiresome and thus abbreviation is a normal part of human linguistic practice everywhere.
“Note the obsessive use of abbreviations and avoidance of capital letters; this is a system invented by people to whom repetitive stress disorder is what black lung is to miners. Long names get worn down to three-letter nubbins, like stones smoothed by a river. “
(except from Stephenson’s classic essay In the Beginning was the Command Line)
If tab expansion is a modern luxury, then so are glass TTYs. If we change perspective to the last 30–40 years, we can consider that that is a long enough time span to change expectations of how a computer interface behaves.
Stephenson’s essay quickly manages to confuse principle with implementation, delving into plain fanboyism toward the end. It is not to be read as a guide how to create computer systems.
I don’t think anybody’s suggesting that the essay is in any way prescriptive. And I agree, the UNIX command line is a pretty lousy UI – but I think having short names for very common commands is hardly the worst thing about it. More to the point, it’s embedded in a long and rich history that includes many worse-is-better design choices, which have proven unfortunately durable for reasons that are worth understanding.
We’re talking past each other. You want to stay in the land of “ought”, while I think we can’t really get much useful work done there without at least attempting to understand why things are the way they are here in the land of “is”.
That word is absurdly difficult to spell and is 11 character long. It would be an awful name.
Then name it something else, like show, type or read.
But it doesn’t read or show or type files, it concatenates them. You could call it join but it’s called cat. Does it matter what it’s called? None of the names actually tell you what it does. join could do all manner of things. type could tell you what type of file it is or allow you to type out a replacement file. show could show the file in full screen analogously to a slideshow. read could read the file aloud.
Given that you need to learn what it does regardless of the name, why does the name really matter? It would be annoying to rename the command and you’re never going to get rid of the original name or overload it anyway because it’s one of the most used Unix commands, so all you’re doing is just taking up more space in the namespace of short commands (which is small) to do something we already have a name for.
If cat concatenates files, how does one display a text file on Unix? Copy it to /dev/lpr?
Learning Unix is an investment that few are willing to do more than once in a lifetime. Imagine if there were two or more systems with a similar, but different stance on user interfaces – one where the command to concatenate files was called ten for conca_ten_ate and ten -u was considered harmful. Since this is a huge investment, those who have done it already become change-averse since it lowers the value of their investment.
But as with anything in computing, even the oldest things are only so old that many of the original pioneers are still alive. There will be new people having to learn that cat displays files “because it con_cat_enates files”, and over the course of time, newcomers will outnumber those who already know and can reap the benefits from knowing.
Tab expansion results in write-only code that is difficult to read. concatenate is too long a name. It gets in the way. Commonly used Unix commands are basically syntax in the language of Unix, they’re function words and not content words. cat is grammatical, not lexical. It’s like have in “I have never been to America”. What do we do with lexical words? We abbreviate them. “I’ve never been to America”. “I’d prefer not to”. Spending 11 characters in a line on grammar is a waste of space that obfuscates the meaning of a script or command.
Sorry, but how can you say that tab-expansion results in write-only code that is difficult to read?
Is “I have never been to America” really more difficult to read than “I’ve ne’er ‘n t’ ‘merica”?
We don’t abbreviate words to make them easier to read, we do it to make them easier to write.
The command for making a directory is mkdir and if I had to type out make directory every time I wanted to make a directory I’d throw every single file I touch or use into my home directory.
Is git a bad name? I know it’s named after Linus Torvalds (har har) but it certainly doesn’t say what it does. The first version control system was called Source Code Control System, or scss. Replacing that was the Revision Control System or rcs. Then of course there’s cvs for Concurrent Version System. But do you have to invent a new synonym for each new one that comes along? Should the next have been vcs for Version Control System, then perhaps git could be called dvcs for Distributed Version Control System, but of course it wasn’t the first of those. Maybe BitKeeper would have been dvcs and git could have been Distributed Revision Manager or drm.
If something is a small utility that genuinely only does one thing and you can abbreviate that one thing down to a single command name that less than 6 characters long, go for it. cc for C Compiler, rvm for Ruby Version Manager, etc. But generally there comes a point at which you want something to just have a name, like git or hg or vi or python.
What works very well to name projects in general is [fantasy name]+[what it does]. The fantasy name (or company name) gives you a namespace. The second part makes it obvious what it does.
Good examples: Apple Mail, GNU C Compiler, Microsoft Paint
Note that from this point of view, having “util” or “tool” in the name makes perfect sense. If a project is named “fyblid”, what should a client program for talking to it be named? “fyblid-util” of course. Or perhaps “fyblidctl”.
Why would you need to type out make directory each time you want to make a directory?
If it makes a directory, name it make directory.
If it makes a directory, name it make directory.
One doesn’t imply the other.
Are you being intentionally obtuse?
Not as obtuse as software designers who couldn’t come up with a better control method than renaming every command as two-letter rebuses.