In the Beginning was the Command Line

cristal.inria.fr

Add Remove

quote We had a human/computer interface a hundred years before we had computers. When computers came into being around the time of the Second World War, humans, quite naturally, communicated with them by simply grafting them on to the already-existing technologies for translating letters into bits and vice versa: teletypes and punch card machines. These embodied two fundamentally different approaches to computing. When you were using cards, you'd punch a whole stack of them and run them through the reader all at once, which was called batch processing. You could also do batch processing with a teletype, as I have already described, by using the paper tape reader, and we were certainly encouraged to use this approach when I was in high school. But--though efforts were made to keep us unaware of this--the teletype could do something that the card reader could not. On the teletype, once the modem link was established, you could just type in a line and hit the return key. The teletype would send that line to the computer, which might or might not respond with some lines of its own, which the teletype would hammer out--producing, over time, a transcript of your exchange with the machine. This way of doing it did not even have a name at the time, but when, much later, an alternative became available, it was retroactively dubbed the Command Line Interface. on 8/13/2020, 4:50:21 AM

fulltext In the Beginning... Was the Command Line on 8/13/2020, 4:50:21 AM

excerpt In effect we still used Victorian technology to communicate with computers until about 1984, when the Macintosh was introduced with its Graphical User Interface. Even after that, the Command Line continued to exist as an underlying stratum--a sort of brainstem reflex--of many modern computer systems all through the heyday of Graphical User Interfaces, or GUIs as I will call them from now on. on 8/13/2020, 4:51:39 AM

authored-by Neal Stephenson on 8/13/2020, 4:52:09 AM

via Nikita Singareddy on 8/13/2020, 4:52:39 AM

excerpt Nothing is more disagreeable to the hacker than duplication of effort. The first and most important mental habit that people develop when they learn how to write computer programs is to generalize, generalize, generalize. To make their code as modular and flexible as possible, breaking large problems down into small subroutines that can be used over and over again in different contexts. Consequently, the development of operating systems, despite being technically unnecessary, was inevitable. Because at its heart, an operating system is nothing more than a library containing the most commonly used code, written once (and hopefully written well) and then made available to every coder who needs it. on 8/13/2020, 5:08:45 AM

excerpt In your high school geology class you probably were taught that all life on earth exists in a paper-thin shell called the biosphere, which is trapped between thousands of miles of dead rock underfoot, and cold dead radioactive empty space above. Companies that sell OSes exist in a sort of technosphere. Underneath is technology that has already become free. Above is technology that has yet to be developed, or that is too crazy and speculative to be productized just yet. Like the Earth's biosphere, the technosphere is very thin compared to what is above and what is below. on 8/13/2020, 5:11:33 AM

excerpt Back in the days of the command-line interface, users were all Morlocks who had to convert their thoughts into alphanumeric symbols and type them in, a grindingly tedious process that stripped away all ambiguity, laid bare all hidden assumptions, and cruelly punished laziness and imprecision. Then the interface-makers went to work on their GUIs, and introduced a new semiotic layer between people and machines. People who use such systems have abdicated the responsibility, and surrendered the power, of sending bits directly to the chip that's doing the arithmetic, and handed that responsibility and power over to the OS. This is tempting because giving clear instructions, to anyone or anything, is difficult. We cannot do it without thinking, and depending on the complexity of the situation, we may have to think hard about abstract things, and consider any number of ramifications, in order to do a good job of it. For most of us, this is hard work. We want things to be easier. How badly we want it can be measured by the size of Bill Gates's fortune. on 8/13/2020, 5:15:53 AM

excerpt Unix is hard to learn. The process of learning it is one of multiple small epiphanies. Typically you are just on the verge of inventing some necessary tool or utility when you realize that someone else has already invented it, and built it in, and this explains some odd file or directory or command that you have noticed but never really understood before. on 8/13/2020, 5:20:37 AM

excerpt 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. on 8/13/2020, 5:21:51 AM

excerpt What made old epics like Gilgamesh so powerful and so long-lived was that they were living bodies of narrative that many people knew by heart, and told over and over again--making their own personal embellishments whenever it struck their fancy. The bad embellishments were shouted down, the good ones picked up by others, polished, improved, and, over time, incorporated into the story. Likewise, Unix is known, loved, and understood by so many hackers that it can be re-created from scratch whenever someone needs it. on 8/13/2020, 5:23:23 AM

excerpt Editor, compiler and linker are to hackers what ponies, stirrups, and archery sets were to the Mongols. Hackers live in the saddle, and hack on their own tools even while they are using them to create new applications. It is quite inconceivable that superior hacking tools could have been created from a blank sheet of paper by product engineers. Even if they are the brightest engineers in the world they are simply outnumbered. on 8/13/2020, 6:00:03 AM

excerpt GUIs tend to impose a large overhead on every single piece of software, even the smallest, and this overhead completely changes the programming environment. Small utility programs are no longer worth writing. Their functions, instead, tend to get swallowed up into omnibus software packages. As GUIs get more complex, and impose more and more overhead, this tendency becomes more pervasive, and the software packages grow ever more colossal; after a point they begin to merge with each other, as Microsoft Word and Excel and PowerPoint have merged into Microsoft Office: a stupendous software Wal-Mart sitting on the edge of a town filled with tiny shops that are all boarded up. on 8/13/2020, 6:11:40 AM

excerpt Over the years that I've been working with Linux I have filled three and a half notebooks logging my experiences. I only begin writing things down when I'm doing something complicated, like setting up X Windows or fooling around with my Internet connection, and so these notebooks contain only the record of my struggles and frustrations. When things are going well for me, I'll work along happily for many months without jotting down a single note. So these notebooks make for pretty bleak reading. Changing anything under Linux is a matter of opening up various of those little ASCII text files and changing a word here and a character there, in ways that are extremely significant to how the system operates. on 8/13/2020, 6:13:44 AM

excerpt Many of the files that control how Linux operates are nothing more than command lines that became so long and complicated that not even Linux hackers could type them correctly. When working with something as powerful as Linux, you can easily devote a full half-hour to engineering a single command line. For example, the "find" command, which searches your file system for files that match certain criteria, is fantastically powerful and general. Its "man" is eleven pages long, and these are pithy pages; you could easily expand them into a whole book. And if that is not complicated enough in and of itself, you can always pipe the output of one Unix command to the input of another, equally complicated one. The "pon" command, which is used to fire up a PPP connection to the Internet, requires so much detailed information that it is basically impossible to launch it entirely from the command line. Instead you abstract big chunks of its input into three or four different files. You need a dialing script, which is effectively a little program telling it how to dial the phone and respond to various events; an options file, which lists up to about sixty different options on how the PPP connection is to be set up; and a secrets file, giving information about your password. on 8/13/2020, 6:14:12 AM

excerpt Presumably there are godlike Unix hackers somewhere in the world who don't need to use these little scripts and options files as crutches, and who can simply pound out fantastically complex command lines without making typographical errors and without having to spend hours flipping through documentation. But I'm not one of them. Like almost all Linux users, I depend on having all of those details hidden away in thousands of little ASCII text files, which are in turn wedged into the recesses of the Unix filesystem. When I want to change something about the way my system works, I edit those files. I know that if I don't keep track of every little change I've made, I won't be able to get your system back in working order after I've gotten it all messed up. Keeping hand-written logs is tedious, not to mention kind of anachronistic. But it's necessary. on 8/13/2020, 6:14:12 AM