Intro to the CLI – Part 1: Why Learn to Use The Terminal and Some History

Long-time fans of GitKraken Client have come to love the graphical user interface, or GUI, that allows you to click on a Git branch or commit to perform an action or even drag and drop a branch to start a pull request. Version 8.0 of GitKraken Client introduced the GitKraken CLI, allowing you to interact with your repositories, and the rest of your computer, from Terminal Tabs.

Developers who already loved working with Git through a CLI rejoiced as they were able to immediately dive in and leverage a terminal interface alongside their favorite Git client. But for other users, this new option might seem a little intimidating if you’re not familiar with a CLI at all. You might even be asking yourself: what does CLI stand for?

“CLI” stands for command line interface, and it is indeed an intimidating interface. Every developer has known the terror of a blank screen with a blinking cursor and nothing to indicate what you should do next. It can seem almost like some form of sorcery!  

But you shouldn’t let fear stop you! Working in the terminal lets you tap into the amazing powerhouse that is your computer in ways that relying on a GUI alone simply doesn’t permit.  Learning to use a command line interface will open a whole new world of possibilities and make you more productive in Git! 

The CLI Stands For – A CLI Intro Series is aimed to help you learn how to embrace the terminal, and in doing so, unlock abilities that might seem downright magical.   

Why Should I Learn How to Use the CLI?

There are a lot of great reasons to learn how to use the command line.  Even in a world where seemingly most applications have a GUI, the command line allows you to accomplish a greater number of things, from navigating and discovering file information to editing photos and videos, faster while providing the ability to automate and scale numerous tasks with ease. Let’s take a closer look at some concrete reasons you would want to embrace using the command line.

Developer Job Skills

If you’re planning to work in the development or DevOps world, you’re going to need to know how to speak the common language of scripting, file system navigation, and open source tooling.  All of that is built on the back of the command line. 

When collaborating with others, it’s common for another developer to suggest a tool to solve a particular need, and obtaining the tool involves cloning a repository. Most of the time, the tool they suggested won’t have a GUI. If you need to install a testing suite that will automatically fire during a CI/CD process, then you’re going to need to know how to configure and operate it from a text-only terminal. If you ever need to use commands like `git reflog`, it’s mandatory to know a little bit about how Git works its magic in the file system, and that comes from understanding the shell. 

GUIs Can Be Limited

GUIs are pretty great for visualizing things, simplifying complex operations and offering a low barrier to entry for users who may be new to Git. We love GUIs at GitKraken! But all of those benefits come at the cost of development time and effort. Very often, the full set of abilities a program has to offer is hidden under multiple layers of menus and in some cases might not be exposed at all. It can become time-consuming digging through menus hunting down what you need.

How a GUI behaves comes down to developer decisions and how they envision people will use an application. To the developer, it might be obvious what happens when you click an icon or select a menu item.  And for the most part, the efforts of GUI developers should be applauded!

The complexities of navigating a GUI can be partially solved by offering command palettes, which are a lifesaver in tools like VS Code and GitKraken Client. A command palette gives you keyboard access to the full menu of functionality, including keyboard shortcuts for the most common operations. Simply type what you want to do and the command palette will show you the options to accomplish that task.  GitKraken Client’s Command Palette lets you configure settings, open and manipulate files, undo and redo actions, and a lot more. 

At its core, many software applications have a command line interface acting as an intermediary between the user and machine. A command palette is basically a way of exposing a tool’s command line interface to help you work faster. For some tools, you will find it is sometimes easier, or even necessary, to work with the command line interface to accomplish certain tasks like configuration changes or task automation. Learning how to use CLIs will help you make better use of the tools you’re already using!

Automation of Repetitive Complex Tasks

You have likely repeated the same monotonous steps, over and over again, to get some bit of work done. One good example is updating a WordPress website’s plugins. You need to log in, click on the updates menu, review available updates, click to update what you want to update, and then manually check to make sure nothing breaks. For a single website, this might not sound too bad, though perhaps a little tedious.

But what if you manage more than one website? Maybe dozens? The manual update path is now going to become a full-time position and will take time away from adding new features or making stakeholder-requested changes. 

One of the real superpowers of using the command line is the ability to automate just about any process through scripting. You will read more about that in the scripting section of this series, but for now, you can think of it like IFTTT or Zappier, which execute actions based on certain triggers, but for anything your computer can do.  Once a script is written, your computer can execute, repeatedly, over and over again, without getting bored or making human errors in the process. 

In the WordPress example, you can build scripts using the CLI that use the WP-CLI to do things like check for updates, apply any updates that exist, and test all pages for breaking changes. Once the script is written, just point it at a list of your sites and let the automation do the heavy lifting, allowing you to get back to focusing on building new awesome web experiences!

Don’t Be Intimidated by a Blank Terminal

People are generally scared of what they don’t understand, such as a blank terminal that gives you absolutely no clues on what to do next. It is completely natural to feel a bit overwhelmed when starting out with command line interfaces. GUIs mostly assume that you will learn as you go through designed intuitive interface features. CLIs, on the other hand, seem to expect you to have a prerequisite level of knowledge about what to type to make something happen.

No one was born knowing CLIs. Every advanced dev had to learn it the same as you are now. Everyone was a complete CLI noob at one point. It’s OK to not know anything as you start learning.  But before you jump in and start typing commands, it’s a good idea to understand where you’re typing and where those commands are being sent.

A Brief History of the Terminal

So what exactly is a terminal and how is that different from a CLI? What on earth is a shell? The answers to those and a lot of other common questions become clear if we take a quick look at how computer interfaces evolved. 

You are likely used to clicking on an icon to open and work with an application, such as a web browser, Slack, or Zoom. But this is not how people originally worked with computers. Think back to a time when computers were the size of rooms and IBM claimed that only 5 would ever be needed. A time when “debugging” literally meant looking for a moth in a circuit relay. How did they interact with those machines? They used punch cards.

These ‘punch cards’ had little holes that basically told the machines a single instruction. You can almost think of them as little telegrams that developers would send to the machine. Stack these punch cards up, run them through the computer in the right order, and you have a working program. As you are correctly thinking, this is a very slow and very error-prone system. 

As computers became more and more common, developers realized they needed a way to interact more directly and quickly with those giant machines.  So, they created the terminal.  A terminal is any way you can give input to and read output from a computer. 

The very first terminals were created in the 1940s and were essentially typewriters that fed paper tape with punched holes into the computer. From that modest start, they quickly evolved to be able to give instructions directly from the keyboard input, without the paper. 

Every time you open a Terminal Tab in GitKraken Client, the included terminal in VS Code, or a terminal application on your machine, you are opening a direct line of communication to the operating system. Once this line of communication is open, we need a way to pass commands to the operating system and to programs currently running on the machine. This is where shells and command-line interfaces, or CLIs, come in.   

Terminals vs Shells vs CLIs

While terminals, shells, and CLIs are very related concepts and are often talked about interchangeably, knowing the difference early on can help you navigate documentation and other learning resources later on. We already defined the terminal above, so let’s define what those other terms mean before we move on to command examples.

Shell vs CLI 

A shell is a computer program that exposes an operating system’s services to a user or a program.  

A command-line interface, or CLI, on the other hand, processes commands to a computer program in the form of lines of text.

You already use shells all the time through a GUI. Every time you move a folder, create a new file or do anything requiring the operating system, you are using a shell. If you are using Windows, you’re using the Windows shell that powers the desktop environment, start menu, and task bar. Mac users are using Quartz Compositor to operate Finder, the Dock, and Mission Control. Linux users are most likely using X Window System to power the UI.

Text-Based Shell Interfaces

A shell does not necessarily need to present a GUI. It can also contain a program that takes text input, interprets it, and sends it along to the operating system. If there is any output, it is presented back in the shell as text. Since you enter the commands as lines of text, one line at a time, these shell programs became known as command line interfaces. Early on, before computers had enough RAM or processing power to draw a GUI environment, all machines only had CLI shells. CLI shells remain popular even today.

In those early days of computer science, it was up to every developer to implement their own shell. As you can imagine, shells at the time took a lot of different forms, which required specialized knowledge to be able to use. Fortunately, the industry adopted Unix, which stood for “Uniplexed Information and Computing Service,” as a standard way to structure operating systems. This standardization for how a computer conceptually laid out a file structure made it possible to share code for shells and paved the way for the modern terminal experience.

Though there was an agreed-upon standard for Unix, it was still up to early computer scientists to create their own versions of Unix. There were a lot of early Unix variations, such as Research Unix, Columbus UNIX, PWB Unix, and many others.  The most popular two by the early 1980s were, AT&T Unix, developed by AT&T’s Unix Support Group, and Berkeley Unix, developed by a team at the University of California, Berkeley. 

Berkeley Unix’s command-line shell utility “sh”, also called the Bourne shell, named after its creator, Steven Bourne, became a wildly popular shell option. Developers liked it because of the ease of writing scripts and the ability to ‘pipe’ outputs from one command into the input of other commands. These concepts will be expanded on in the scripting section of this series.  

Open Source Shells

By the early 1980s, computers were going through a serious change. For the first time, ‘home computers’ were an affordable reality for computer hobbyists. An entirely new era of innovation started as people building or tinkering with their own computers started to share ideas and software freely and openly. This was in very stark contrast to the proprietary nature of computing up to that point. The movement was labeled “Open Source Software,” or OSS. The open source model encouraged sharing ideas by sharing actual source code, so users could learn from and reuse work from other people freely and openly. 

One of the early projects to come from the open source movement was GNU, which stands for Gnus Not Unix. GNU is a collection of free software that can be used as an operating system, or used in part with other operating systems. Of course, GNU also needs a shell to interact with the terminal.

The GNU project created one of the most popular CLI shells ever written, which is still in use on millions of machines around the world. It was an implementation based on the abilities of the Bourne shell, so they called it the “Bourne again shell”, or Bash.

If we look at the history of Git, we see that when Linus Torvalds came up with Linux years later, he didn’t need to build his own command line shell; he simply used Bash. The ramifications of this decision are still with us today. All Unix-like operating systems, also commonly referred to as *NIX systems have a version of Bash included. macOS is included on that list. 

This standard way of approaching a CLI shell means, as a developer, you can easily move between machines and still get your work done. You can write working code that can be shared between users and machines with different operating systems. It means there’s a common language between all devs on how to think about and interact with the OS. Even Microsoft’s Windows has finally gotten aboard the Bash bandwagon with the introduction of Windows Subsystem for Linux.

One final note before moving on: Bash is one of many CLI shells out there. In 2019 Apple switched from Bash as the default shell in the terminal, to using Zsh, which itself is just an extended version of Bash. You might find you prefer one over another, and that’s just fine.  The examples in this series use Zsh, but all commands will work just fine in Bash and many other shells. 

CLIs for Applications

Many programs and development tools have their own command line interfaces. A lot have no GUI at all. Git is a good example of a program that is, by default, used through a command line interface. GitKraken Client has exposed this powerful interface and now you can do so much more than Git in the client and keep in the developer flow.

In another section, you will take a look at a few of those applications, as well as how to get and install them. Before diving into additional applications though, it’s important to understand a few CLI shell basics that will enable you to interact with your file system more directly and with a greater amount of control.  

Nothing to Fear But Fear Itself!

For a lot of people, part of their fear of the command line comes from not wanting to mess up their computer. It likely took you days or weeks to get things set up ‘just right’ for your use cases. It doesn’t help that there are stories floating around out there about people deleting the wrong thing and blowing up their machines and costing them hours or days of recovery time. While possible, it’s actually pretty rare to encounter such devastating issues.

Modern operating systems have a lot of safety precautions built in by default that make it very hard to cause catastrophic accidents. Combine that with a good backup strategy, and you will find that it’s actually very hard to mess things up so bad that you can’t recover. In fact, most of the time, the worst-case means just re-cloning a repository and losing a tiny bit of work. For the examples we will be covering, the stakes are even lower than that.   

As with so many other things in life, the benefits of learning to use the command line far outweigh the risks.  It will give you an understanding of your computer deeper than any GUI can give you. With that understanding comes power and a whole realm of possibilities.  Have courage, open your mind and let’s embrace the command line! And stay tuned for the next CLI Stands For – Intro to the CLI series.