When getting into programming, you may be surprised by how many people use the command line tools. Using the command line definitely looks cool, but are there any tangible benefits besides more respect from your peers?
Text everywhere
With the command line interface (CLI), almost all of your input is text—which allows you to type just commands and their options. And typing is a fast and precise input method when you compare it to clicking with a mouse on the screen.
When people build programs that use a graphical user interface (GUI) as their main input, they are limited by what fits onto the screen. They can expand their options by adding many levels of nested menus or multiscreen forms, but even this solution has its limitations if the interface is to be easy to use. To a text-based program, one can always add one more flag, and the only impact on other users would be the help page getting slightly longer.
In the CLI, most of the output is just text as well. This makes it effortless to produce a lot of complicated output, and the user can quickly scan it to get the information they need. You can see the power of text-based communication in GUI programs too: often, when an operation fails, you get an error log in a text form.
Everything integrates smoothly
Plain text is a format that has allowed different programs to integrate smoothly since the introduction of the pipe operator | in the 1970s. It predates by decades XML (1999), or various approaches to web APIs:
- REST—defined in 2000,
- GraphQL—made public in 2015
What’s better is that whereas other formats come and go (have you heard about SOAP?), plain text is here to stay. There is nothing simpler than dumping text to standard output; and your operating system allows feeding the output from one program to another. You can trust people will build new tools that fit into this workflow, no matter what other standards come and go in the meantime.
Shell will be there for you
Most people take GUIs for granted—they’ve been the de facto standard in consumer electronics since 1990. But while working as a programmer, you will have to deal with machines that are not optimized for ease of use—for example:
- cloud machines used as servers,
- continuous integration (CI) agents,
- old computers with bare-bones operating systems that are still used to save costs, and
- other nonstandard setups, such as Raspberry Pi and smart devices.
In such cases, command line access is often the best you can hope for. And even if you could run a graphical operating system, it will be more resource draining. The safe, performant bet is to use text only.
Another important aspect of CLI: as an interface of choice for many programmers, many key tools used in programming are built this way. For example:
- Git
- compilers
- Docker
- pretty much anything that you would run at your CI
With time and growing popularity, those tools can get some GUI clients. Unfortunately, those clients will always be an afterthought, and at best they will support the basic workflows. Often those are developed by some third party—so you depend on the original tool, and an independent provider, or the GUI client. If the GUI developer abandons their projects, then you will get stuck with an old version, or you will have to find and learn a new one.
Shell knowledge compounds
Everything new that you learn, you can use with any other program you know already. When you learn programs one by one, they don’t look impressive:
ls—to show filesgrep—to search for textcat—to show content of one or many filesxargs—to run a command with many argumentsless—to display content as scrollable text on the screenwc—count characters, words, or lines
Everything changes when you realize each tool adds to the toolset you have, so you can
- get all files containing a string (for example
class) with grep and display their content on screen with xargs, cat, and perhaps less, as well as
- list all the files with
ls, filter them to the ones that end with .spec.js with grep, and count with wc.
No matter what CLI tool you learn, you will be able to combine it with all the others that you already know. The interaction possibilities are limited only by your creativity—you don’t depend on third parties to support each other’s API. Everything just works together.
Script
Text-based tools are great for automatization. At a minimum, you can easily write a list of various commands to be run one by one. If you are up to the challenge, you can even use some conditional statements (if, switch). The syntax of shell scripts gets complicated quickly, but in any case, it’s simpler than automating clicking around with a cursor.
Even though the command line has a retro vibe to it, it’s a safe, long-term investment. If you check when some of the commonly used tools were first released, you can be sure that they will stay with us a few decades more:
Most of the common Unix tools are open source—so you can assume that as long as there are people using them, then there will be some community support as well. The open-source nature helps the new tools to draw from older ones, letting things evolve. A great example is the history of Neovim—currently my editor of choice:
- Neovim is a modernized but backward-compatible version of Vim. Neovim was forked from Vim in 2015.
- Vim itself stand for Vi IMProved. Vim was published in 1991.
- Vi grew from a visual mode of ex, which is still available even in Vim and Neovim as the normal mode. Vi was originally released in 1976.
- ex was a user-friendly editor inspired by ed, the original Unix text editor. Ex was developed in 1973.
As you can see, even when those tools are replaced by something newer, their legacy often lives on in another generation of tools. What’s great about this longevity is that very different tools end up using the same conventions and commands. Ed inspired not only the normal mode of Vim, but also different tools:
- a command line text editor, Sed
- the search utility grep
Thanks to this shared history, as you learn something new in one place, you can use it in the related tools as well.
Want to learn more?
I hope I’ve convinced you to start learning the basics of the command line! I’ll be publishing articles about CLI basics; if you’re interested in learning more about this topic, please sign up here.
