A blank screen and a blinking cursor. That’s all that greeted users when they booted up their machines in the early days of personal computing. No start menu. No icons. Just the command line.
For many budding developers, that blinking cursor presented a mystery to be solved or an invitation to adventure. “It felt magical,” says Toby Padilla, co-founder of Charm, a company that makes tools for building command line applications. “You expected to be able to do anything if you could find the right commands.”
When command lines were first introduced, they were actually much more approachable than the punch card-based interactions that came before. But to those raised on graphical user interfaces (GUIs), the blinking cursor can be intimidating. Yet even as GUIs have displaced text-based command-line interfaces (CLIs) for mainstream users, the command line has remained part of most tech workers’ day-to-day tasks. If anything, the rise of cloud computing and DevOps have made the command line more important to software developers, system administrators, support specialists, and other professionals over the past decade.
“Sometimes it’s faster to do something in a GUI, where you can just click a button or a menu and not have to remember anything or look up a command,” says dbatools maintainer Chrissy LeMaire. “But many tasks are easier and more efficient on the command line. I can migrate an entire database with just one command instead of having to click through a series of menus.”
The CLI has been around for decades, but there’s still room for innovation as a growing number of open source projects tackle issues to take the command line into the future. Decades from now, the command line will probably still be with us. But we can already see it evolving.
Why the command line is key
The command line experience consists of at least three related things:
A shell, which is a language, usually designed specifically for interacting with the underlying operating system, and an environment for processing that language. Bourne is the grandparent of today’s most popular shells, including Bash, Z shell, and PowerShell.
A terminal, which is an application for interacting with shells and other applications. Windows, macOS, and typical Linux distributions come with a default terminal but there are many others available.
Text-based applications that you can launch and interact with through a terminal, such as Git, Grep, and Curl.
One reason for the enduring popularity of the command line is that it’s far easier to write a CLI application than a GUI application. You don’t even have to think about, let alone design and code, all the menus and buttons required for a GUI. That means many small or niche applications — the sorts of things designed to scratch a developer’s own particular itch — often begin as CLI-only tools. It’s only after one of these applications has gained widespread use that someone might take the time to add a GUI.
But there are other reasons to use text-based applications even when a GUI is available. CLI apps are often the easiest to stitch together. “You can take the text output of one app and use it as the input for another app,” says Padilla. “That enables you to follow the Unix philosophy and take small tools that do one thing and do them well and chain them together to do things that the original creators never intended. It’s just much harder to do that sort of thing with GUI applications.”
And then there is the aforementioned efficiency of typing a few commands over digging through drop-down menus. “There are just so many things that are easier on the command line, such as file structuring, creating new directories, searching for files with grep,” says Katerina Skroumpelou, a senior software engineer at Narwhal Technologies. “And you can script all of these tasks to use them later.”
Oil shell creator Andy Chu emphasizes the importance of scripting to the longevity of the command line. Remember: Shells aren’t just an interface. They’re also a language for interacting with and automating computers. The rise of the cloud has made automation more important as technical teams are faced with managing ever-greater numbers of virtual machines and containers. “The cloud is really a whole lot of Unix machines,” Chu says. “And shell is still the best interface we have for the cloud.”
The command line is also part of tech culture. Practitioners assemble shell configurations, CLI tools, and workflows over years and years of work. These personalized collections are points of professional pride. “Working from the command line has always been fun for me,” says LeMaire. “It just feels cool, and makes me think of hackers and the movie War Games.”
Commands on the tip of the tongue
As powerful as the command line is, it can have a steep learning curve and be especially off-putting to new users. Error messages can be frightening, documentation confusing, and default “Help” commands overwhelming. “It’s intimidating at first,” Skroumpelou says. “It’s just hard to know what you can or should do sometimes.”
All of this puts a cognitive burden on the user. Even seasoned pros sometimes need to look up commands they don’t use often. Anton Medvedev, a site reliability engineer at Google, created Zx, a tool that makes it easier to incorporate Bash into JavaScript, because he kept forgetting how to do things in Bash that he did routinely with JavaScript. “It’s just easier for me to, say, split a string with JavaScript without having to look up the syntax,” he explains
There are autocomplete packages for all major shells—some, like Fish, actually include completions by default. But IBM’s Command Line AI (CLAI) R&D project aims to provide more sophisticated assistance for Bash users. One of its modules attempts to translate natural language requests into the correct shell commands and syntax. For example, if you typed “compress Documents folder,” CLAI will recommend the corresponding Tar command.
As helpful as AI could be in augmenting faulty human memory, the lower-tech solution of simply providing more beneficial error messages is a step in the right direction as well. “The first time I used PowerShell, it would throw exceptions for simple mistakes like trying to run the ‘dir’ command on a directory that doesn’t exist,” LeMaire says. “There was lots of scary red text for something that is, fundamentally, not a big deal. They’ve come a long way with PowerShell 7 in making errors more informative and less alarming with the ErrorView option that allows for concise output.”
Toward a more charming command line experience
In addition to being mentally taxing, the command line experience often just feels uninviting. Terminals don’t always behave the way one would expect. For example, users of modern applications expect to be able to use a mouse or touchscreen to position a cursor within a string of text. But that’s not the case with most terminals, including the ones included by default in Windows and macOS.
Fortunately, there are lots of tools available to customize just about any shell. Fonts and themes can be altered. If there’s a command you keep forgetting or hate typing, you can create aliases that are shorter and easier to remember. Thanks to tools like Z shell configuration framework Warp and the PowerShell theme engine Oh My Posh, it’s easier than ever to share and discover custom configurations, plugins, and themes.
But the out-of-the-box experience can still be challenging. New users might not know how to change their configurations or realize what sorts of tools and plugins are available for their shell. A proprietary macOS terminal called Warp aims to create a more user-friendly experience by default, regardless of what shell you use. In addition to AI-assisted command search and autocomplete, it challenges many of the basic interface assumptions about the terminal interface and experience in an effort to make it more powerful and user-friendly. For instance, in Warp, every command’s output is grouped with its input, similar to in a Jupyter notebook. This added structure makes it easy to copy/paste or share the results of terminal commands. The Warp client, which co-founder Zach Lloyd says will eventually be cross-platform and open source, looks and feels a bit like a cross between a chat client and an integrated development environment (IDE). And you can interact with text the way you would in any other desktop program, placing the cursor where you want and cutting and pasting to your heart’s content.
Warp demonstrates how much room there is to improve the basic command line experience. “The autocompletion features are what made me try Warp,” says Skroumpelou. “But the interface is great as well. It leaves you wondering why we’ve been doing things the way we have for so long.”
CLI application developers can also take steps to make their tools more friendly, regardless of what shell or terminal they’re used in. For example, the Charm and Textualize teams offer a number of tools designed to help developers to create more visually rich textual user interfaces within traditional terminals. Lip Gloss, for example, is a library that gives developers CSS-like style definitions for CLI apps, while Bubble Tea provides a set of reusable interface components—including text inputs, progress bars, and timers—and Gum provides tools for incorporating these elements into apps and shell scripts.
Even as the command line becomes more visually appealing, CLI app developers need to keep accessibility in mind. For visually impaired users, the command line’s plain-text interfaces can be more accessible to screen-readers and other assistive technologies. But a study conducted by Google and presented in 2021 found that screen-reader users often struggled with scrolling through large text outputs in the terminal. The paper outlines several considerations that CLI app developers can follow, including making documentation available in HTML and ensuring that status updates and progress meters are screen-reader-friendly.
Power tools: Structure and programmability
Experienced programmers and admins are like wizards in the command line. But there’s still more power to be gleaned from the console. One relatively recent development — in the grand scheme of things — is the idea of outputting structured text from the command line in a more standardized format, which makes it more efficient to chain command line applications together in sophisticated ways.
With structured data inputs and outputs on the command line, you can easily do things like filter the data you send from one app to another, send different parts of the output to different destinations, or perform transformations on the data before sending it.
For example, if an app returns an object with file names and their corresponding creation dates and file sizes, you could filter the file names by creation date or file size before piping them to another app. Or you could pipe the file names and sizes into separate destinations or calculate the total file size of all the files and pipe only that number.
All of this is possible to do in a traditional shell, like Bash, that supports only plain, unstructured text by default. “The preferred way to handle more structured inputs and outputs is through loadable built-ins, which, I suppose, can be thought of as the Bash equivalent of plugins,” explains Bash maintainer Chet Ramey. “You can also impose structure on data the shell reads and manipulate it using shell variables.”
But some shells were designed specifically to handle structured data. PowerShell, introduced in 2006, popularized the use of structured data in the command line and it’s been picked by other shells such as nushell. The catch, however, is that it can be hard to convince developers to switch to a new shell, given the amount of investment so many have not only in learning particular languages but accumulating tools and tweaks for their existing setup.
“PowerShell does a good job of supporting structured pipelines, but Bash is so powerful and widely supported, it’s hard to justify putting in the effort to learn a different shell,” says Medvedev, the Google engineer who built Zx.
But while Bash continues to release new features and updates, drastic changes to the way the language works could break backward compatibility and, by extension, countless shell scripts that are currently keeping computing infrastructure running around the world.
“There’s this huge body of existing Bash code out there: scripts, config files, common idioms that people use, and the like,” Ramey says. “I have to be very cautious about breaking those things.”
Rather than switch shells, Medvedev would rather have the ability to use a language he’s already familiar with — JavaScript in his case—within the Bash environment. Zx is a step in that direction, but he still can’t run JavaScript commands directly within the shell.
The barrier to implementing Medvedev’s multilingual future for the command line, Chu says, is that it’s technically difficult or impossible to use languages like JavaScript or Python as 1:1 replacements for shell languages like Bash. In order to create a migration path from Bash to Oil shell, the project supports both a Bash-like language and a JavaScript and Python-influenced language.
The other problem with trying to supplant established shells like Bash or Z shell is that, well, it takes a long time to build a full-fledged replacement. “It’s even harder than I thought it would be,” says Chu, who has been working on Oil shell since 2016.
Meanwhile, there’s plenty of room for innovation that doesn’t depend on terminal or shell-specific features. Padilla, for example, expects to see more cloud services and APIs designed to be used from the command line, which is why Charm also makes tools for building backends for CLI apps. He points to SSH keys as an under-utilized terminal feature . “It’s much easier to build backend applications when terminals are the expected client,” Padilla says. “You can use SSH for authentication, which is much easier than dealing with authentication over web protocols.” He cites GitHub's SSH/Git API as an example of an existing “CLI-first API.” The ability to easily make calls to more remote APIs from the terminal opens up the potential to pipe the responses from those APIs into other CLI apps or even rapidly chain APIs together in much the same way you chain local CLI apps together. None of this requires new shells or terminals.
It’s too early to say what sorts of new CLI-first cloud services might emerge, but there are many opportunities for new CLI tools in the cloud management and automation space, from collaboration to working with observability data.
Looking at all these themes together, an image of the future of the command line emerges. It’s not just a more visually rich and accessible experience, but one that bundles many helpful tools by default and provides more intuitive ways to learn, or recall, commands and syntax. The command line will also be more powerful as support for structured data becomes more seamless and networked tools provide new opportunities to work together in the natural habitat of the developer.
