Do I need to memorize every command?

No. A working set of a few dozen commands (cd, ls, cat, grep, find, chmod, ps, kill, curl, ssh) covers most day-to-day work; the rest you look up when you need them, the same way experienced users do.

What's the difference between bash, sh and zsh?

They're all shells - programs that read and run the commands you type. sh is the original, minimal POSIX shell; bash extends it with more features and is the default on most Linux distributions and servers; zsh extends bash further and is the default on modern macOS. Scripts meant to run anywhere are often written for sh's narrower, more portable syntax.

Is the command line the same on macOS as Linux?

Mostly, since both are Unix-like, but not identical - some common tools (like sed and find) have different flags between macOS's BSD versions and Linux's GNU versions, which occasionally breaks a script copied from one to the other.

How do I practice without breaking anything?

A cloud VM, a Docker container, or a virtual machine on your own computer gives you a disposable Linux environment where a mistake costs nothing - it's normal to break a throwaway environment on purpose while learning what a command does.

Git, Linux & DevOps

The Linux Command Line

The command line - a shell such as bash or zsh - is a text interface for a Unix-like operating system: instead of clicking icons, you type commands that move through directories, read and edit files, manage processes, and chain small tools together. Most servers, cloud instances, containers and CI runners have no graphical interface at all, so the shell is often the only way to interact with them. Learning it is less about memorizing every command and more about learning a small, composable set of tools and how to combine them.

Why it matters

Most production systems have no GUI: Cloud VMs, containers and CI runners are typically accessed only over SSH or a terminal, so deploying, debugging or checking logs happens on the command line.
It's faster for repetitive or bulk operations: Renaming a thousand files, searching every file in a project for a string, or restarting a service is one command in a shell and many clicks in a GUI.
Scripting turns manual steps into repeatable automation: A sequence of shell commands saved as a script is the basis of most deployment scripts and CI pipeline steps.
It's the shared language across Docker, CI/CD and cloud tooling: Dockerfiles, GitHub Actions steps and most infrastructure tooling run shell commands under the hood, so reading and writing them is a prerequisite for the rest of DevOps.

Moving around and looking at files

A handful of commands cover most navigation: pwd shows where you are, ls lists what's there, cd moves between directories, and cat or less show a file's contents. Paths can be absolute (starting from the root, /) or relative (starting from wherever you currently are), and mixing the two up in a script is a common source of it working in one directory and failing in another.

Composing small tools with pipes and redirection

Unix tools are deliberately narrow - grep searches text, find locates files, sort orders lines, wc counts them - and the pipe operator (|) feeds one command's output into the next as input, letting small tools answer questions no single command answers alone. Redirection (> and >>) sends output to a file instead of the screen. This philosophy of small, composable tools is one of the command line's defining ideas, not just a convenience.

Shell

# find every .log file modified in the last day and count error lines
find /var/log -name "*.log" -mtime -1 | xargs grep -l "ERROR" | wc -l

# list the five processes using the most memory
ps aux --sort=-%mem | head -5

Permissions and processes

Every file has an owner, a group, and read/write/execute permissions for each, shown as a string like rwxr--r--; chmod changes those permissions and chown changes ownership. Every running program is a process with a process ID (PID); ps and top show what's running, and kill sends a process a signal, most commonly asking it to stop.

Shell

chmod 644 deploy.sh      # owner can read/write, everyone else read-only
chmod +x deploy.sh       # add execute permission for everyone
ls -l deploy.sh          # -rwxr--r-- 1 alice staff 812 Sep 16 deploy.sh
kill -9 4821              # forcibly stop the process with PID 4821

Mistakes people make here

Running rm -rf on the wrong path: there's no trash can - it deletes immediately and permanently. A stray extra space (rm -rf / home instead of rm -rf /home) has destroyed real systems; destructive commands, especially with wildcards, deserve a second look before pressing enter.
Not understanding relative vs absolute paths: a script that works when run from one directory can silently fail, or touch the wrong files, when run from another; using absolute paths, or explicitly cd-ing, in scripts avoids this.
Treating sudo as a routine prefix: running everyday commands as root bypasses the permission system meant to contain mistakes; it should be reached for deliberately, not out of habit.
Ignoring exit codes: every command returns a status code (0 for success), and a script that chains commands without checking it can keep running after an earlier step actually failed.
Not knowing how to read man pages or --help: the flags shown in a blog post or forum answer may not match the version installed; the authoritative description of a command's options is a keystroke away.

Strengths and trade-offs

Where it is strong

A small set of composable tools (grep, find, sed, awk, sort) covers a huge range of tasks when piped together.
Almost everything can be scripted and automated once it works interactively.
Available, in near-identical form, on every Linux server, most cloud shells, macOS, and Windows via WSL - the skill transfers everywhere.
Remote systems can be operated exactly like local ones over SSH, with no extra tooling.

The trade-offs

The learning curve is real: command names and flags are terse and inconsistent between tools for historical reasons.
There's no undo for destructive commands like rm - mistakes are permanent unless backups exist.
Shell scripts get unreadable fast past a certain size; a real scripting language is usually a better choice once a script grows past a page or two.
Different shells (bash, zsh, sh) and different Unix flavors (Linux vs macOS) have small but real syntax differences that trip up scripts moved between them.

Who needs this

Anyone who will deploy, debug or operate software outside their own laptop's GUI, which in practice is almost every backend, DevOps or infrastructure role. Frontend-only or mobile-only work can get by with less, but basic navigation and file commands come up everywhere.

Questions about the linux command line

Do I need to memorize every command?: No. A working set of a few dozen commands (cd, ls, cat, grep, find, chmod, ps, kill, curl, ssh) covers most day-to-day work; the rest you look up when you need them, the same way experienced users do.
What's the difference between bash, sh and zsh?: They're all shells - programs that read and run the commands you type. sh is the original, minimal POSIX shell; bash extends it with more features and is the default on most Linux distributions and servers; zsh extends bash further and is the default on modern macOS. Scripts meant to run anywhere are often written for sh's narrower, more portable syntax.
Is the command line the same on macOS as Linux?: Mostly, since both are Unix-like, but not identical - some common tools (like sed and find) have different flags between macOS's BSD versions and Linux's GNU versions, which occasionally breaks a script copied from one to the other.
How do I practice without breaking anything?: A cloud VM, a Docker container, or a virtual machine on your own computer gives you a disposable Linux environment where a mistake costs nothing - it's normal to break a throwaway environment on purpose while learning what a command does.

The primary source

Related concepts

Git and GitHubVersion control fundamentals, and the collaboration workflow built on top of them.Docker and ContainersPackaging an application with everything it needs so it runs the same way everywhere.

← All concept guides