Command Line

A terminal (or terminal emulator) is the program that gives you a text window and handles keyboard input and screen output. A shell is the program running inside that terminal that reads what you type, interprets it, and runs commands — bash is the default shell on the overwhelming majority of Linux distributions, though zsh and others exist. When you SSH into a server, you are connecting directly to a shell session — there is no terminal emulator involved on the remote end in the GUI sense, just a shell reading from and writing to your SSH connection.

Three commands answer the three questions you ask constantly when working blind on a remote server: `pwd` (print working directory) tells you where you are, `ls` lists what's in the current directory, and `cd` changes into another directory. These sound trivial, but on an unfamiliar server with no GUI, "where am I and what's here" is the very first thing you establish before doing anything else — treat it as a habit, not a formality.

A few commands round out basic orientation: `whoami` and `id` tell you who you're logged in as and what groups you belong to (critical before you assume you have permission to do something), `hostname` tells you which machine you're actually on (easy to forget when you have six SSH sessions open in different tabs), and `history` shows your recent command history — genuinely useful for reconstructing "what did I just run that broke this".

Every shell command follows roughly the same shape: `command [options] [arguments]`. The command is the program to run. Options (also called flags or switches) modify how it behaves, conventionally prefixed with a single dash for short form (`-l`) or double dash for long form (`--all`) — and many commands let you combine short options together, so `ls -l -a` and `ls -la` are equivalent. Arguments are the actual targets the command operates on — a filename, a directory, a username.

This structure is a convention, not a hard rule enforced by the shell itself — the shell just splits your input on whitespace and hands the pieces to the program, which decides for itself what counts as an option versus an argument. That's why most, but not all, commands follow this pattern consistently, and why reading a command's `--help` output or man page matters more than pattern-matching from memory when you hit an unfamiliar tool.

Two commands you'll use constantly to learn any other command's syntax: `man <command>` opens the full manual page (press `q` to quit, `/searchterm` then Enter to search within it), and `<command> --help` prints a shorter usage summary directly to the terminal. When you're unsure whether a flag exists or what it does, check one of these before guessing — guessing with an unfamiliar flag on a destructive command is exactly how production incidents start.

An environment variable is a named value available to your shell and every program it launches — think of it as configuration that travels with your session rather than being hard-coded into any single program. You reference a variable's value with a `$` prefix (`$HOME`), and set one with `export NAME=value` (in bash). Common ones you'll see constantly: `$HOME` (your home directory), `$USER` (your username), `$SHELL` (your default shell's path), and `$PWD` (current working directory, kept in sync automatically by the shell).

`$PATH` deserves special attention because it explains one of the most common early confusions: when you type a command name like `ls` without a full path, the shell doesn't search your entire filesystem for it — it only checks the directories listed in `$PATH`, in order, separated by colons, and runs the first matching executable it finds. This is exactly why "command not found" for a program you're certain is installed usually means the directory containing it isn't in your `$PATH`, not that the program doesn't exist — and why running an executable in your current directory needs an explicit `./` prefix (`./myscript.sh`), since the current directory is deliberately not included in `$PATH` by default for security reasons (imagine a malicious file named `ls` sitting in a directory you `cd` into).

Variables set with plain `VAR=value` exist only in your current shell; `export VAR=value` makes that variable available to any program the shell launches afterward (its "child processes"), which is why you'll see `export` used for anything a script or program downstream needs to read, and plain assignment for values only the interactive shell itself needs.