You open a terminal for the first time in and stare at a black screen with a blinking cursor. You type something. You press Enter. Nothing happens. No confirmation, no progress bar, no “Done!”, just the cursor blinking back at you like it’s waiting for something else.
So you type it again. Still nothing. You close the terminal and go back to clicking around in a GUI.
That’s how most people’s first experience with the terminal ends. Not because the command was wrong. Because the terminal was working exactly as intended, and nobody explained how it actually behaves before handing it to you.
There’s a concept in psychology called the curse of knowledge. Once you know something well enough, you lose the ability to remember what it felt like not to know it. The thing that was once confusing becomes invisible, not because it stopped being confusing, but because your brain quietly filed it away and moved on.
Terminal guides are written almost entirely by people who are deep under the curse of knowledge. They know what the $ symbol means. They know why the screen goes blank after a successful command. They know what happens when you press Ctrl+C. None of it registers as something that needs explaining anymore so they skip straight to the commands, and beginners hit a wall they never saw coming.
This isn’t a guide about commands. It’s about the six things that will confuse you before you even get to commands, the behaviors that feel broken until you understand why they exist.
These are the six that get everyone.
1. When it says nothing, that means it worked
Coming from graphical interfaces, you’re trained to expect feedback. You save a file, the title bar updates. You install software, a progress bar fills. Something always confirms that the thing happened.
The terminal doesn’t work like that.
When a command succeeds, you get your prompt back. That’s it. No checkmark, no “Success!”, no output of any kind. Just the cursor, ready for the next command.
$ cp cypress/fixtures/user.json cypress/fixtures/user.backup.json
$
That blank line isn’t the terminal ignoring you. The file was copied. The terminal is done. It moved on.
This is a deliberate design choice, not an oversight. The philosophy is that output means something went wrong, or you specifically asked for information. Silence means everything went fine. Once you internalize that, it actually feels clean, you’re only reading output when there’s something worth reading.
But until it clicks, every successful command feels like a failure.
2. Your password is invisible and that’s intentional
The first time you’re asked to enter a password in the terminal, you type it and watch nothing appear. Not dots, not asterisks. Nothing. The cursor just sits there.
The natural assumption is that the keyboard has stopped working. It hasn’t.
The terminal hides password input completely, not even placeholder characters, to prevent what’s called shoulder surfing. If someone’s watching your screen, they can’t tell how many characters your password is, which gives them nothing useful. Even the length of your password stays hidden.
$ sudo pacman -Syu
[sudo] password for adrian:
Type your password and press Enter. It’s being captured. The blank input is the feature.
3. The $ in tutorials is not part of the command
Every terminal guide, every Stack Overflow answer, every documentation page shows commands like this:
$ cd Documents
$ npx cypress run
$ php artisan serve
The $ is the prompt symbol. It’s what the terminal prints to indicate it’s ready for input, it’s marking where your command starts, not contributing to it. When you see $ npm install, you type npm install.
You’ll also see % on Zsh, # when running as root, and sometimes no symbol at all. The character varies, but the role is always the same: it’s a separator between the terminal’s state and your input.
Nobody explains this upfront because to anyone who’s been using a terminal for more than a week, it stopped registering as something that needed explaining. But copy-pasting that $ is one of the most common things that breaks a first command.
4. Ctrl+C does not copy, it kills
In every other context, Ctrl+C copies selected text. In the terminal, it sends an interrupt signal that stops whatever is currently running.
If you’re running a test suite, a server, a long install, or anything else that’s actively executing, and you reach for Ctrl+C trying to copy something, you’ve just cancelled it.
$ npx cypress run
Running: login.cy.js (1 of 8)
Login flow
✓ loads the login page (432ms)
✓ logs in with valid credentials (1204ms)
- should redirect after login
^C
That ^C in the output is the terminal’s way of showing you the interrupt happened. Six test files never ran. The process is gone.
To copy in most terminals, the shortcut is Ctrl+Shift+C. To paste, Ctrl+Shift+V. The extra Shift is the only difference between copying text and killing a process.
Once you know what it actually does, Ctrl+C becomes one of the most useful things in the terminal. Stuck in a command that won’t finish? Ctrl+C. Accidentally started something you didn’t mean to? Ctrl+C. It’s the universal escape hatch. Just not for copying.
5. If you accidentally open Vim, here’s how to get out
At some point running git rebase -i, forgetting the -m flag on a commit, or following a tutorial that assumes you know what you’re doing, you will end up inside Vim without meaning to. You’ll know because the screen looks nothing like a normal editor, your keyboard seems to be doing unpredictable things, and there’s no visible way to close it.
$ git commit
# Vim opens automatically because no -m flag was provided
# The screen fills with your diff and a blinking cursor
# Nothing you type makes sense
The exit commands:
Without saving: Press Esc, type :q!, press Enter.
Saving and exiting: Press Esc, type :wq, press Enter.
That’s all you need for now. The reason the keyboard feels broken is that Vim is a modal editor, it operates in different modes, and the same key does different things depending on which mode you’re in. When you first open it, you’re in normal mode, where most keys are commands rather than characters. Pressing g doesn’t type the letter g. It does something else entirely.
Esc returns you to normal mode from wherever you are. From normal mode, :q! quits without saving and :wq saves and quits. You don’t need to understand anything else about Vim to get out of it, and getting out of it is usually all you need.
6. Different tutorials show different commands and they’re all correct
You follow a guide that tells you to run one command. You follow another guide and it shows something completely different for the same task. Both claim to be correct. One of them doesn’t work on your machine.
This isn’t a mistake. It’s because “the terminal” isn’t one thing.
The terminal is the window. The shell is the program running inside it and the shell is what actually interprets your commands. Different shells have different syntax, different built-in commands, and different defaults. The most common ones you’ll encounter are Bash (the default on most Linux systems and older Macs), Zsh (the default on macOS since Catalina), and Fish (a friendlier alternative some developers prefer).
Most of the time the commands are identical across shells. But not always. Array syntax, certain string operations, some scripting features, these behave differently depending on which shell you’re in. A script written for Bash won’t necessarily run correctly in Fish.
On top of that, the operating system matters. A guide written for Ubuntu will use apt. The same guide for Arch-based systems uses pacman. On macOS you’d reach for brew. On Windows, you’re likely in PowerShell or WSL, and neither of those behaves like a Unix shell by default.
# Ubuntu / Debian
sudo apt install git
# Arch / CachyOS / Manjaro
sudo pacman -S git
# macOS
brew install git
# These do the same thing. Different OS, different package manager, different command.
When a command isn’t working and you’ve typed it correctly, the first thing to check is whether the guide was written for your system. The second thing to check is which shell you’re actually running. You can find out with echo $SHELL. Most of the time, that’s the answer.
The people writing terminal guides have been using the terminal long enough that these behaviors stopped being noticeable. The invisible password, the silent success, the $ symbol… none of it registers as something that needs explaining anymore. It’s been second nature for so long that the gap between their experience and a first-timer’s isn’t visible to them.
The result is that beginners hit these moments, feel like they’re missing something obvious, and conclude the terminal is just not for them. That’s not a skill problem. It’s an orientation problem.
The terminal is an old interface with a lot of implicit conventions that nobody wrote down because everyone who used it had learned from someone who already knew. Once you see what those conventions are, the rest of it, the commands, the flags, the piping, all of it, starts making sense a lot faster.
The six things above aren’t edge cases. They’re the first six walls. Most people hit at least three of them in their first session.
Now you know they’re coming.
Top comments (0)