When getting into programming, you may be surprised by how many people use 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 ?), 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. SOAP 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. Basic tools of the industry 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: —to show files ls —to search for text grep —to show content of one or many files cat —to run a command with many arguments xargs —to display content as scrollable text on the screen less —count characters, words, or lines wc Everything changes when you realize each tool adds to the toolset you have, so you can get all files containing a string (for example ) with and display their content on screen with , , and perhaps , as well as class grep xargs cat less list all the files with , filter them to the ones that end with with , and count with . ls .spec.js grep 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 ( , ). The syntax of shell scripts gets complicated quickly, but in any case, it’s simpler than automating clicking around with a cursor. if switch Eternal toolset 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: —1973 grep —1989 Bash —1977 AWK 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: is a modernized but backward-compatible version of . Neovim was forked from Vim in 2015. Neovim Vim Vim itself stand for IMProved. Vim was published in 1991. Vi Vi grew from a visual mode of , which is still available even in Vim and Neovim as the . Vi was originally released in 1976. ex normal mode ex was a user-friendly editor inspired by , the original Unix text editor. Ex was developed in 1973. ed 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 Also Published Here

Developers Like to Use Shell - Here's Why

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

3 Steps to Adding End-to-end Tests to Your Project

31 Stories To Learn About Command Line

Developer’s Toolkit: 4 linux command-line tools for debugging everyday issues that all developers…

5 cool things you can do with the Sanity CLI

9 Fun Command-Line Tools to Make Your Life Easier

A gentle introduction to Git and GitHub

3 Steps to Adding End-to-end Tests to Your Project

31 Stories To Learn About Command Line

Developer’s Toolkit: 4 linux command-line tools for debugging everyday issues that all developers…

5 cool things you can do with the Sanity CLI

9 Fun Command-Line Tools to Make Your Life Easier

A gentle introduction to Git and GitHub

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps