P-2.1 The Command Line

What this is and why it exists

Every build tool assumes a command line. So does every deployment system, and every server you will ever log in to. Avoiding the terminal means avoiding most of the work.

The good news is that the set worth knowing is small, and it stops growing quickly. Navigation, looking at files, redirection, pipes, searching. That is most of it.

One habit separates comfortable users from nervous ones. Comfortable users read the documentation already installed on the machine. Nervous ones search the web for a command sitting three feet away.

The vocabulary

• Shell — the program that reads your commands and runs them.
• Working directory — where the shell currently considers you to be.
• Path — a location in the file system, absolute or relative.
• Standard output — where a command writes its results by default.
• Redirection — sending that output into a file instead of to the screen.
• Pipe — sending one command's output straight into another's input.
• Manual page — the documentation installed alongside a command.
• Permissions — the rules deciding whether you may read, write or run something.

The mental model

Start with location, because almost every early mistake comes from one cause. You were in a different directory than you thought. Printing where you are and listing what is there removes most of those mistakes, and it costs two keystrokes.

Next, looking at files without opening an editor. Reading the first lines of a large file. Reading the last lines of a log. Searching inside one. These are faster from the shell than from any editor, and you will use them every working day for the rest of your life.

Then the idea the whole shell is built on. A command's output does not have to go to the screen. It can go into a file, and it can become another command's input. That is what makes small single-purpose tools worth having: they compose. A tool that only sorts is useful precisely because its output can feed a tool that only counts.

Searching is two different problems, and confusing them wastes a lot of time. Finding a *file* by its name is one tool. Finding *text inside* files is another. Being able to answer "where is this defined?" without opening an editor is worth practising on purpose.

Finally, two walls you will hit. The first is not knowing what a command does. Its documentation is already on the machine. It is more accurate than most of what a search returns, because it describes the version you actually have. The second is a permission error. That is not a mysterious refusal. It is the operating system telling you this user may not do this thing. It is usually one flag or one ownership question away from being understood.

What you should now be able to explain or do

Print where you are and list what is there without thinking about it. Read the head of a file, the tail of a log, and search inside both. Send output into a file, and pipe one command into another. Say why finding a file and finding text inside files are different jobs. Read a command's installed manual instead of searching for it. Recognise a permission error for what it is.

Check yourself