What the CLI is and why developers still use a black window

There are two ways to talk to a computer. The first is the graphical interface: mouse, icons, folders, windows. It is comfortable, intuitive, and familiar. But when you work with servers, configure software, or write code — the mouse suddenly becomes a bottleneck.

CLI (Command Line Interface) is the alternative: you type a command in text, the computer runs it, and gives you a result back. No graphics. No buttons. Just text. And for many tasks, it is significantly faster.

If you have ever seen a hacker in a movie endlessly typing into a black window with white letters — that is roughly what it looks like. But don’t worry: reality is much more boring and much more useful.

The problem: why are we still doing this

Modern operating systems did everything they could so people wouldn’t need to type commands. But there are situations where the CLI is unavoidable:

Servers don’t have a mouse connection. Most servers run without a monitor or graphical shell. You connect remotely (via SSH), and the only thing you see is a command line. Without it, you simply can’t do anything with that server.

CLI is automation. If you can do something with one command, you can do it a thousand times in a loop or on a schedule. Try automating mouse clicks through a GUI — it doesn’t end well.

CLI is precision. In a graphical interface, you often do things slightly wrong: wrong folder, wrong file, wrong option selected. In the CLI, you write exactly what you mean: which file, which name, which action. It is like writing instructions instead of gesturing.

How this works in plain language

The CLI has two main components:

Terminal — the window program where you see the command line and type text. On Linux — any terminal emulator (gnome-terminal, xterm, Konsole), on macOS — Terminal or iTerm2, on Windows — Windows Terminal.

Shell — the program behind the window. It reads what you type, interprets it, and tells the operating system what to do. The most famous is bash, but there are others: zsh, fish, PowerShell.

When you type a command, here is what happens:

  1. The shell reads the text.
  2. It finds the program that handles that command.
  3. It runs it with the specified parameters.
  4. It shows the result on screen.

Basic commands everyone will need

You don’t need to learn everything at once. Start with the basics:

ls              # list files in the current directory
ls -la          # detailed list: permissions, sizes, modification dates
cd /path        # change to a directory
cd ..           # go up one level
pwd             # print working directory (show where you are)

Creation and management

mkdir new_directory      # create a directory
touch file.txt           # create an empty file
cp original.txt copy.txt # copy a file
mv old_name.txt new_name.txt  # rename or move a file
rm file.txt              # delete a file (careful!)

Reading and searching

cat file.txt             # print the entire file
head file.txt            # show the first 10 lines
grep "word" file.txt     # find lines containing "word"
find /path -name "*.txt" # find all .txt files

Network and processes

ping google.com          # check internet connectivity
curl https://example.com # make an HTTP request
top or htop              # show running processes
ps aux                   # list all running processes

How flags work

Flags are extra parameters that change how a command behaves. They are written with a single or double dash:

ls -l           # long format: with permissions, sizes, dates
ls -a           # show hidden files (starting with .)
ls -la          # both long format and hidden files
curl -I https://example.com  # only response headers, no full body
curl --max-time 10 https://example.com  # 10-second timeout

Practical rule: if you don’t know what a flag does — man <command> will tell you everything.

Pipes: when you need to combine commands

One of the best things about the command line is the ability to chain commands together. The | (pipe) symbol takes the output of one command and feeds it as input to the next:

ls -la | grep ".txt"           # show only .txt files
cat log.txt | grep "error" | wc -l  # count how many lines contain "error"
ps aux | grep node | awk '{print $2}'  # find PIDs of processes with "node"

It is like a toy set: you assemble the behavior you need out of small blocks.

How to understand error messages

The CLI doesn’t always speak politely. Sometimes it says permission denied, sometimes command not found, sometimes something that looks completely unreadable. But the answer is usually pretty specific:

Commands usually return an exit code: 0 means success, any other code means failure. Check it with echo $? right after running a command.

Common beginner mistakes

1. Being afraid of the terminal

That’s the most common mistake. The terminal won’t bite you. Sure, you can delete the wrong file, but as long as you don’t run commands blindly and don’t copy suspicious things without reading them, nothing catastrophic will happen.

2. Copying commands without understanding

The internet gives you ready-made commands that can break your system. Always understand what a command does before pressing Enter. Do not put sudo just because a tutorial said so.

3. Deleting things as root

sudo rm -rf / — never, under any circumstances. It will wipe your entire filesystem. Even variants of this command with different paths can be dangerous if you’re unsure.

4. Not checking where you are

Before running a command — especially one that deletes or renames — always check pwd and ls. One typo in a path and the file is gone. Checking takes a second and saves hours.

5. Ignoring man pages

man ls, man grep, man curl — that’s full documentation right in the terminal. You don’t need to Google it. Usually command --help is enough for a quick overview of available flags.

Conclusion / action plan

The CLI isn’t black magic. It is the language you use to talk to the computer. If you are a developer, a DevOps engineer, or just curious about how things work — the command line will become one of the most useful tools in your kit.

Here’s what to do next:

  1. Open a terminal and see what you see (usually the current working directory path and a cursor).
  2. Type ls and then ls -la — compare them.
  3. Create a directory, cd into it, create a file, read it — complete the basic cycle.
  4. Try grep and | (pipe) — combine two commands.
  5. Look up help for any command: command --help or man command.

The day you can do 10 things in 30 seconds through the terminal (and realize how long it would have taken with a mouse), you’ll come back.