The graphical user interface (GUI) became the standard in the early 90s. It replaced the older, text-based interface. It made computers more accessible to everyone. So why do we still see people working on text-only terminals?
It’s fast
The keyboard is the fastest and most precise input interface for computers. Each finger has a few keys within reach, and an average user can type two or three letters each second. Compare it with a mouse—it has only a few buttons, scroll, and an X-Y axis. It’s suitable only for picking one of the predetermined options from the screen. And there will be at least a few seconds between clicks.
Because of those shortcomings, most graphical applications have keyboard shortcuts. To use computers efficiently, you need to learn a lot of them; it’s almost painful to see people copy and paste without using system shortcuts. Unfortunately, most GUIs are not very efficient in teaching the shortcuts—often, it’s on the user to search for the shortcuts for their most common actions.
On the other hand, in a CLI, everything is text-based. Some applications are run in one long command, such as git, grep, sed, etc. Other applications open a text-only interface where every operation is performed with keyboard shortcuts—for example, Vim, Emacs.
Manages complexity
A text-based program can accept any number of switches, and you need to know only about the few you use. Have you ever thought about how many parameters the web browser Chromium can take? More than 1000 (source). They are there, ready to use if you ever need them. But most of the time, they are hidden out of sight—unless you start reading the documentation.
The same feature-richness is not achievable in GUI-based applications. Less common features either clutter the screen or hide inside huge, multi-layer menus. What you get instead are:
- simple programs for simple use cases with an accessible interface
- professional programs with scary interfaces, where it’s difficult to find even basic options
Scripts
Command-line programs take text as an input and give text as an output. On the input/output level, all CLI programs are compatible. For example, you can list all files in your repository with git ls-files, and then use grep to filter it—you just need the pipe operator to achieve it:
$ git ls-files | grep index
home-page/index.html
registration/index.html
index.js
The pipe operator gives you access to computing superpowers that are unimaginable in the graphical world. Things like
- creating thousands of folders or
- finding all files matching or containing some pattern and performing some operation on all of them
are pretty simple and require a bit of online search, reading documentation, and trial and error.
User interface
Because of those reasons, the command line is a primary interface for many programs. So, as a user, you are almost forced to use it. The best example of that is Git: you have some GUIs for it, but using them creates another abstraction level on the data you’re managing. If Git is a tool you use every day, you will benefit from learning its CLI. My impression is that the GUI allows you to achieve 80% of your goals, but then you might encounter a weirder case where the command line is the only way to address it.
This article was first published here
