What the command line actually is

That intimidating black window is just a place to type instructions to your computer, one line at a time. The program listening there is called the shell: you type a command, press Enter, and it does the work and types something back. Think of it as texting your computer instead of clicking at it.

The shell can't touch the hardware directly. It passes your real requests down to the kernel, the deep core of the operating system that actually opens files, talks to the disk, and runs programs. You speak to the shell; the shell whispers to the kernel.

Reading the prompt

Before you type anything, the shell shows you a little line called the prompt. It usually ends with a dollar sign, like `

Moving around: your map

Your files live in folders inside folders, like rooms inside a building. Three commands are your whole map. `pwd` asks "where am I standing?" `ls` asks "what's in this room?" And `cd` means "walk into that room." That's genuinely most of what you need.

$ pwd
/Users/you/projects
$ ls
notes.txt   website   photos
$ cd website
$ pwd
/Users/you/projects/website

Doing things, and the secret report card

To run a command, you type its name and press Enter — that's it. `mkdir photos` makes a new folder called photos; `echo hello` simply prints the word hello back to you. The shell does the thing, shows any result, and hands the prompt back so you can go again.

Here's the part beginners rarely notice: every command quietly hands back an exit code when it finishes. Zero means success; any other number means something went wrong. You don't usually see it, but scripts and tools read it constantly to decide whether to keep going.

$ ls notes.txt
notes.txt
$ echo $?
0

Power moves: pipes, flags, and scripts

A pipe, written as `|`, connects two commands so the output of the first becomes the input of the second — like joining two garden hoses. `ls | wc -l` lists your files and feeds that list straight into a counter, giving you a tidy total instead of a long wall of names.

Most commands also accept flags — little switches starting with a dash that change behavior. `ls -l` shows a detailed list; `ls -a` reveals hidden files. You can usually stack them, like `ls -la`. Flags are how one command quietly does many jobs.

When you save a bunch of commands into a file, you've made a script. But before the system will run it, you must mark it as runnable using file permissions — the `+x` below literally means "allow execute." It's the difference between a recipe you can read and a recipe the kitchen is allowed to cook.

$ chmod +x deploy.sh
$ ./deploy.sh

Reaching another machine

Sometimes the computer you want to control isn't in front of you — it's a server in a data center far away. SSH is the secure tunnel that lets you open a command line on that remote machine and type as if you were sitting at it. You connect with one line like `ssh [email protected]`, and from then on your commands run over there, not here.

On any machine, local or remote, some settings live in environment variables — named values the shell keeps in its pocket, like `HOME` or `PATH`. Commands read them to know where things are. You saw one already: `$?` is just a special variable holding the last exit code.

Recap: a survival cheat-sheet

You now have enough to walk around, look at things, and make the computer do work — all by typing. Keep these few commands close, try them on a folder you don't mind poking at, and the black screen turns from scary into your fastest tool.

1. pwd — where am I right now?
2. ls — what files are here? (add -la to see everything)
3. cd folder — go in; cd .. up; cd ~ home.
4. echo $? — did the last command succeed? (0 = yes)
5. command1 | command2 — pipe the output of one into the next.
6. chmod +x file — make your script runnable.