Why are terminal consoles still used?

  • As we all know, terminal consoles come from a time where there wasn't any chance of graphical interfaces, so the need for them is more than obvious.

    With the appearance of graphical interfaces, many new applications were possible, but also most of those text-only programs moved to its graphical counterpart.

    However, terminals persisted, and not only that: there are services that usually mention this as a feature. The most common example on hand is hosting services.

    Of course, this means that, instead of clicking a button and editing a file, a user needs to memorize hundreds or thousands of commands and then do something like

    sudo nano /www/var/html/myfile.html

    and then navigate with a graphical cursor to edit something and then ctrl+X and Y and choose file to save to. In other words: the anti-usability at its best(worst)

    The same can be seen for many other commands, the above was just an example. A very easy one: WordPress 1-click install vs install WordPress from command line

    So my question is: is there a logical reason why terminals are still used (basically, a technological reason, or a security reason) or is this just a cultural thing that persisted some way despite all its issues?

    EDIT: Adding another case: git. I know there are GUI for git, and they're far more user friendly than git on terminal. Then... why does the terminal version exist?

    I have removed all comments on this post. If you (anyone) have an answer to leave then please do so, but this is not a discussion forum - if you have conversations you want to have then then take it to [chat].

    A small point of order: if a file requires "sudo" to edit, you would probably need to enter a password, or at least answer a challenge, if you tried to edit it in a GUI app — assuming you had equal privileges in both interfaces.

  • Tim Grant

    Tim Grant Correct answer

    5 years ago

    From a UX perspective, terminal consoles have a few key advantages over GUI's. These advantages are rarely relevant to end-users, which is why CLI's are used almost exclusively by technical users and "power users" these days.

    Things done in a terminal are easily repeatable.

    Imagine needing to configure 5 computers for some purpose. For this small number, it's probably not worthwhile to create an automated solution to configure them all. You'll just tweak the settings of each.

    On a terminal, it's simple to copy and paste the commands. On a GUI, you might get familiar with where the configurations are stored, but may still be left with a fair deal of clicking. Mistakes are more likely.

    This also is relevant to documentation and technical help. Providing four lines to copy and paste into a terminal console might replace a couple paragraphs of explanation of how to click into various admin tools (especially since the GUI directions might only be perfect for one of several interfaces, see “GUI interfaces are countless” below).

    Tracking/auditing is easier

    A command-line interface (CLI) retains a record of what you've done, which you can easily extract and keep. When something goes wrong your boss asks, "Are you sure you did it exactly right?" you can have evidence to prove you did. Even if you did make a mistake, you can more easily see it and learn from it.

    Scripting/automating is nearly as easy as entering commands

    Everyone knows how to use a mouse to open a file in a GUI. Far fewer people know how to make that happen automatically. With a CLI, automating the task can be almost as easy as typing it in by hand.

    Technological Constraints can still make CLI's compelling

    Logging into a GUI box remotely requires a fair deal of bandwidth, and latency (delay in the connection) can make the experience frustrating. A CLI remote login has a much lower bandwidth requirement, since it is just transmitting a little text back and forth. And latency is much easier to deal with when you are typing, than when you are trying to hover a mouse over an icon.

    A CLI can be used for Input/Output

    Some have called this The Age of the API, where systems are built on top of systems. A CLI allows a similar interoperability. In the question's example about Git, it would be possible to hook another "enterprise system" - such as a defect tracking system.

    Compared to a SOAP or even Rest API, CLI commands can be easy to develop and test.

    There are just a few standard shells; GUI interfaces are countless

    If you log into the GUI admin interface of a few different web hosting services, you’ll probably see that they are all different. It’s not hard to poke around and figure out where everything is, but it takes time. Next year, the host may have upgraded their solution, and now everything is in a slightly different place — one more thing to learn.

    That hosting service probably still uses the same CLI. The new version is backward compatible with the old. Users familiar with Bash, PowerShell, or whatever CLI is on the system can eliminate the ramp-up time spent familiarizing (or re-familiarizing) themselves with that particular GUI.

License under CC-BY-SA with attribution

Content dated before 7/24/2021 11:53 AM