Command
A command is a single instruction typed into a shell or script that names a program, built-in function or alias to run, together with the extra information that tells it what to do and what to do it to. Where the shell is the interpreter that reads the line, the command is the unit of meaning it reads: one named action, such as copying files, searching text or starting a server, with a defined way of reporting whether it worked.
A command line has a predictable anatomy of a name, options and arguments, and understanding the roles keeps unfamiliar commands readable. In the line cp -r photos backup, the first word, cp, is the command name, which the shell resolves either to a built-in or to an executable file found in one of the directories listed in the PATH variable. The token -r is an option (also called a flag or switch) that modifies behavior, here by copying directories recursively, while photos and backup are arguments, the things operated on. Short options use a single hyphen and one letter and can often be combined, as in ls -la, while GNU-style long options use two hyphens and a word, such as --recursive. The shell splits the line into words and hands the program an array of strings, conventionally called argv, so the program, not the shell, decides what each word means.
Every command ends by returning an exit status, a small integer that tells the caller whether it succeeded, and this is the contract that makes automation possible. By long-standing Unix convention, zero means success and any nonzero value means some kind of failure, with the specific number documenting which one: grep, for example, returns 0 when it finds a match, 1 when it finds none and 2 for an error, so a script can distinguish no results from a broken command. Shells expose the previous status through a special variable and use it in conditionals, in the operators that chain commands so that the second runs only if the first succeeded, and in options that abort a script at the first failure. Windows batch files expose a similar value as errorlevel, and the idea underlies the pass or fail signal of every continuous integration step.
Not every command is a separate program, and the difference affects behavior in ways that surprise newcomers. Built-ins such as cd must run inside the shell itself, because a child process cannot change its parent's working directory, whereas external commands such as ls or python are executable files started as new processes. Aliases and functions add further layers by letting a user define a short name for a longer line. The command that actually runs can be revealed with tools such as type or which, and name collisions explain many bugs in which a script uses a different version of a tool than expected. Commands also read from standard input and write to standard output and standard error, which is what allows them to be chained by pipes and redirected to files.
The command-line model remains central to modern computing because text commands are precise, repeatable and easy to record. Version control (git commit), package managers (pip install), container tools, cloud provider interfaces and machine learning training launchers are all driven by commands whose options encode hyperparameters, paths and device choices, and a command copied into documentation or a notebook reproduces an action exactly. The matching pitfall is that commands usually do exactly what is typed, without a confirmation or an undo: a recursive deletion with a mistyped path, or an option that means one thing in one tool and something else in another, can be irreversible, so reading the manual page and testing on harmless data first are standard habits.
Read a command as a tiny, self-describing contract: a name chooses the action, options and arguments supply the details, standard streams carry the data, and the exit status reports the outcome, which together let humans and scripts combine thousands of independent tools reliably.