This is my newest post in my series about operating systems. Yes, it was last updated in 2019 – I’m a hobbyist blogger. This is a post about the command line, a computer topic, but it is for educating a non-technical (but tech-curious) audience. Most of the programmers in my audience will already know everything I have to say, and may be bored by some explanation of things they already know, though I intend to discuss some technical details of how computers work.

This is not a tutorial on how to use the command line on any particular operating system. Rather, it is a discussion of the role that a command line plays in a modern operating system and why some people (including me) still use that kind of interface.

As I’ve explained before, I often use my computer through the command line. It is a major part of but not the entirety of how I interact with it. I do this so much that people looking at my computer will assume I’m programming even when I’m not – even when I’m working on my blog, or another writing project, or even just organizing my pictures.

Here is a screenshot of a command line session:

Graphical User Interfaces#

This is (as you likely know since you’re reading this on a website) no longer the normal way to interact with computers. Nowadays, we usually interact with computers through graphical user interfaces (GUIs), and many people take them for granted. We access applications¹ through each having their own window – or, for web applications, we can combine them into one window via browser tabs.

We navigate these applications through the mouse, or touchpad. Scrolling and clicking to find our way through the document, right-clicking or navigating menus to find further options, and occasionally interacting with a “dialog box” to specify details. All features are expected to be discoverable, that is to say, we expect to be able to find them in a menu, a toolbar, a right-click menu, or by navigating the dialog boxes we reveal through these other things. If we cannot discover a feature by these mechanisms, we can reasonably assume the application does not have this feature.

Here is LibreOffice Calc, a (somewhat old-fashioned) GUI program:

Nowadays, applications often run inside web browsers. This principle of discoverability is still considered important. Here is Google Docs, an application running inside a web browser:

These are both mouse-navigated programs with discoverable features. For both of these applications, there are many visible ways to interact with them. If you want to find a feature, looking through what’s right in front of you is the way to go.

The Command Line in Brief#

The command line works differently.

Nowadays, the command line is usually accessed via a window within the context of a graphical desktop environment², but in the olden days, people interacted with computers via dumb terminals that couldn’t display images, just text³:

“It was a dummy terminal, and I was a dummy user.”

• A member of the Baby Boomer generation describing what it was like to be a person in a non-IT role using Unix in the 80s.

Instead of being able to find various features via menus visible on the screen, you are instead given a prompt, an indication of the current state of your session that is, well, prompting you to tell the computer what to do, to give it a command:

You can then type your command, maybe a few more.

As you type commands, the output of the commands displays on the subsequent lines. When you hit the bottom of the screen, the screen scrolls up. Most terminal emulators let you scroll the window to see earlier parts of the transcript. A command might also prompt for additional input, or take full control of the terminal emulator and provide a different type of (still text-based) interface entirely.

If you type a bad command, it is not very helpful:

There is no discoverability. There are no hints as to what commands might be accepted. You can use the command line to find out more information about what commands are accepted, but you have to know the commands to do that. In practice, you have to learn a minimal set of commands from a book (or nowadays, a website) before you can actually do anything productive.

It’s not intentionally user-unfriendly. For example, on Linux, there are commands like man (for “manual”) that explain what commands do, and commands like apropos to search for useful commands. Here is the manual page for the man command itself:

Additionally, once you know the name of a command or utility, you can generally find out more about how to use it by passing -? or --help:

Command lines are available on all modern operating systems for personal computing: Windows, macOS, Linux, and certainly any other Unix you might have running. They tend not to be available on mobile OSes.

What is the command line not?#

Before we talk about what this is for, and why modern operating systems still support this decidedly old-fashioned way of interacting with them, I want to dispel some myths and misconceptions about the command line, specifically two opposite misconceptions that seem to still be common amongst the computer laity.

Misconception One: The command line is literally DOS, the Microsoft operating system from the 80’s and early 90’s. It is there to support old programs from the 80’s and early 90’s, and exists solely for the support of obsolete and obsolescent software.

This misconception is common among Windows users, because it used to be true. Until Windows XP, Windows still came bundled and intertwined with a version of Microsoft’s older, fully command-line operating system, DOS. Old DOS programs were still in common use, and people needed a way to run them, so they could run a copy of DOS inside a window.

It’s not true anymore, however. Windows is no longer a chimera of DOS and more modern components. Since Windows XP, both the consumer and business versions of the Windows brand have been versions of Windows NT, a different operating system from earlier consumer versions of Windows, one originally targeted at business users, with no DOS code in it at all.

On a modern Windows computer, the command line is not primarily for DOS programs. The ability to run DOS programs isn’t even shipped with Windows by default anymore, but the command line still is. The confusion is understandable, because the command line still looks like the DOS command line. The prompt is still a form of DOS’s famous C:\>.

What is the command line for, then? It is for running modern Windows programs that happen to be designed to be used from the command line. Windows comes with a bunch of such programs, for things like systems and network administration.

There are a bunch more that you can download install, usually tools written by computer professionals for other computer professionals. Many of these command line programs were written primarily for Linux and other Unix OSes, but also have Windows versions.

We will go into specific examples of command line programs in a later section, but the important thing to know is that a command line program has access to all the same system libraries and capabilities that any Windows (or Linux, or macOS) program can access. It can play audio, connect to the Internet, and do pretty much anything – anything except draw a new window on the screen, not because it can’t, but because that would make it not a command line program anymore.

But I don’t want to go too over-the-top rebutting this first misconception, because then I might lead you to believe the second misconception.

Misconception Two: Not only can you do anything from the command line that you can do from a graphical user interface, but the command line is fundamentally closer to the operating system. When graphical programs run, they are using the command line under the hood.

This is not true.

It should be obvious that there is at least one thing you can do from a graphical user interface that you can’t do from the command line, which is to display graphics. The command line is an interface based fundamentally on displaying a grid of text. Thanks to modern Unicode, “text” now includes “emojis,” but it does not include images or high-quality charts and graphs.

But even with that overly-obvious caveat aside, yes, it is true that anything a graphical program can do besides show graphics could be done by a command line program as well. There are command line programs that manipulate images, they just don’t show the images as they manipulate them. There are command line programs that pretend to be web browsers and scrape data off of the websites when they load. All the operating system features and computer resources that graphical programs have at their disposal, command line programs will generally have too, besides (by definition) actually doing graphical displays and interactions.

However – and this is a big however – just because a command line program could exist to do everything a graphical program does, doesn’t mean that you have that program installed on your system, or that someone’s even ever written that program. The capabilities of your computer depend on what software you have installed, and what software you can install depends on what software people have written. If someone creates a file format, but only writes a GUI program to edit it, well, then, until someone reverse-engineers it, that file format will only be editable via GUI. Similarly if they only create command line tools – that file format will then only be accessible by command line.

For example, someone with ImageMagick installed on their computer but not Photoshop may only be able to do image manipulation from the command line. Someone with Photoshop installed but not ImageMagick may only be able to do image manipulation from the GUI. There is nothing intrinsically more powerful about either interface.

Specifically, GUI programs are decidedly not wrappers around command line utilities. You could write a GUI program that way (and there are a couple that are), but the vast majority do not in fact do this. Just as command line programs have access to all the same computer resources and operating system functionality that GUI programs do, it also works the other way around. GUI programs and command line programs both are written in programming languages that allow the program to invoke operating system functionality through system libraries and system calls. These calls are not at all the same as command line commands, and the GUI doesn’t need to use the command line as an intermediate layer.

If there is a GUI version and a command line version of the same functionality, maybe this is implemented as the GUI version launching the command line version under the hood – that is certainly something GUI programs can do, and it might make sense if the command line version is the interface most people use and that most maintainers are interested in. But it is just as likely if not more likely to be implemented by the GUI program and the command line both using the same common library.

And certainly, GUI-only programs like web browsers, e-mail clients, and office suites do not by any means implement their functionality by wrapping command line programs. There is no command line version of or interface to Photoshop, nor of Microsoft Word⁴.

And just like it’s possible to have an operating system with a command line and no graphical user interface, it is possible to have an operating system with a graphical user interface and no command line, not even internal analogues of it.

History of the command line#

As I said before, computers used to be frequently accessed via dumb terminals. Before this, they were accessed by teletypewriters. This was literally a typewriter, where the keys you entered went to the computer, and the computers responses were typed on the paper.

Modern command lines mostly follow that pattern – new input goes in at the bottom of the window, and the window scrolls like a piece of paper receding from the typewriter. But on a modern command line, the program can also take over the entire terminal emulator window, as long as what it wants to draw can be expressed as text. They even support multiple colors.

Most command line systems used today, like most operating systems used today, descend from the Unix tradition, written in 1970. The exception is Windows – even though the Windows command line is not DOS, it takes many of its aesthetic principles from DOS, not only the famous prompt C:\>, but also its habit of taking options with /, where Unix and friends use -.

What are some modern command line programs?#

• git keeps track of different versions of a large folder (called a repository) full of code or other forms of (mostly) text, and allows changes to be merged and reconciled between different authors. While there are GUI and web wrappers around it, the flagship program is a command line utility.
• ssh lets you log into a command line interface of another computer, usually a server. This is often the only way to log into and administrate the server, as Linux servers generally don’t have any GUI capabilities or GUI programs installed.
• ImageMagick lets you manipulate images.
• Last but not least, there are many small programs that let you do basic file management, searching, and editing. Two of my favorite new ones are RipGrep by Andrew Gallant (which lets you search for strings or patterns in text files) and fd by David Peter (which let you search for files by name or other properties).

Why use the command line?#

If you are new to a tool, discoverability is an important feature. If you are experienced with a tool, all the hints of where to find things are more distractions than they are useful.

As someone who needs all the focus that I can get⁵, distractions are bad. And so are extra steps: Why spend the time moving the mouse around to access one menu, then another, when on the command line, I can just type the command I already know for what I need to do.

Additionally, the command line is designed to save on extra typing. Generally, most modern command lines support “tab completion,” where you can type the beginning of the command, or a file that it’s operating on, and press the [TAB] key, the command line interpreter will complete the word for you – or list the possibilities if there are multiple.

For a newbie, it might be an intimidating, but for someone who’s used to it, it stays out of your way and lets you get stuff done – while showing you a detailed transcript of what you’ve been doing, in case you forget what exactly it was you were trying to do.

Command lines are even more important on the server. While Windows servers come with a graphical user interface you can remote login into, Unix⁶ servers generally don’t. It’s more efficient to just allow administrators a command line interface – and for most server administrators, it’s quite enough.

And while command lines are not closer to the operating system in a deep technological sense, they are closer to the operating system by convention. They tend to have all the options that a power user would want – and easy ways to specify them, rather than hiding them behind multiple warning signs and buttons labelled “Advanced….”

Last but not least, if you have a series of GUI actions that you often do, you usually have to just keep doing them, even if it’s very tedious. Precious few programs let you do something like write a shortcut key for five menu commands. On the command line, however, you can use aliases or scripts, where a short command stands for a long command, or a single command stands for a whole sequence of commands. You just put into a file the same text you would type at the prompt.

How does the command line actually work?#

Generally, a terminal emulator or command line window has a process running in it that presents the prompt (C:\> or similar on Windows, normally something ending with $ on Unix). It then takes in the command, takes the first word, and runs that as a program. This program is launched as a separate process, just like clicking on a program icon launches a separate process in a graphical user interface. The shell waits in the background for the process to finish, and then presents a new prompt. On a modern multitasking operating system, the shell generally also allows you to run commands in the background, and use key combinations (Ctrl-Z on Unix) to put a process in the background, and commands like fg to bring processes back to the foreground. This allows you to run multiple programs at once within the terminal.

On Linux, when a program starts, it conventionally has three open files, 0, 1, and 2, for input, output, and error, respectively. On the command line, by default (for it is configurable), these all correspond to the terminal: input is read in from the keyboard on the terminal (by default line by line), and output and errors are outputted to the terminal. GUI programs will have these three files open when they start too, but unless they’re started from the terminal, the output will normally just silently be ignored.

The program can also draw a window, if a graphical environment is available. On Linux, it is easy for the same program to have a command line interface, and a graphical interface – sometimes at the same time. This is useful if it’s mostly used from the command line, but sometimes also wants to do things like show a chart or graph that can be generated.

macOS and Windows have more complicated GUI frameworks that make a GUI application more different in structure from a command line operation, but you can still launch GUI applications from the command line.

Footnotes#