Linux Basics: Command Line Mastery

Imagine you are on a phone call with your cousin, guiding her to a specific notebook inside your house — but she cannot see anything, and you cannot point. You cannot say "that one" or click an icon. You have to say something precise: "Go to the second shelf. Open the middle drawer. Inside, there is a blue folder. Open it. The notebook is the third item." Every instruction has to be exact, typed out in words, because there is no picture to lean on.

That phone call is exactly what happens every time you use a Linux command line. When you use a phone or a laptop with icons and a mouse, you are pointing at pictures and letting the computer guess what you mean. When you use a command line, you are talking to the computer directly, in precise text, the same way you guided your cousin. It feels slower at first, but it is far more powerful — because precise text instructions can be saved, repeated a thousand times, sent to someone else, or run automatically at 3 a.m. while you sleep. A click cannot easily do that. A line of text can.

This is not a niche skill. The Linux kernel sits underneath Android, which means the phone in your pocket is, technically, running Linux. Nearly all the servers that power the websites you visit, the supercomputers ISRO and other research institutions use for weather and space simulations, and most cloud infrastructure worldwide run Linux. When you eventually write Python programs, install a package, or use Git to save versions of your code, you will be typing commands into a shell — the same kind of interface you are about to learn here. This chapter builds that skill from the ground up, correctly, with no hand-waving.

The Terminal and the Shell: Who Is Actually Listening?

Two words get mixed up constantly, so let us separate them cleanly. A terminal is just the window on your screen — a blank box where you type and where text appears. It is a display, nothing more. The program actually reading what you type, understanding it, and running it is called the shell. The most common Linux shell is called bash (short for "Bourne Again SHell"). Think of the terminal as the telephone, and the shell as the person on the other end who understands your language and acts on your words.

When you open a terminal, the shell greets you with a prompt — a short line telling you it is ready to listen. A typical prompt looks like this:

aditi@aici-vm:~$ 

Read it left to right: aditi is the username currently logged in, aici-vm is the name of the computer (its "hostname"), and ~ (called tilde) is shorthand for "your home folder" — you will meet it again shortly. The $ symbol marks the end of the prompt and means "ordinary user, type your command here." (If you ever see # instead of $, it means you are logged in as the root user — the administrator account that can do absolutely anything, including permanently break the system. Treat a # prompt the way you would treat a fire alarm switch: know it exists, but do not touch it casually.)

Everything you type after the prompt is a command. You press Enter, the shell reads it, runs it, prints any result, and then shows you a fresh prompt, waiting for the next instruction. This loop — read, run, print result, wait — repeats for every single thing you do at the command line.

The Filesystem Is a Tree, Not a Desktop

On a phone or a Windows/Mac desktop, you experience files as icons scattered across folders that you click open one at a time. Linux organizes every single file and folder on the entire computer into one giant structure shaped like an upside-down tree, starting from a single point called the root directory, written as just a forward slash: /. Every file, every program, every folder you will ever touch is a branch somewhere under that one root. There is no separate "C: drive" or "D: drive" the way there might be on Windows — everything is one connected tree.

Here is a simplified version of that tree, with your personal files living several branches deep inside it:

Under the root, a handful of standard directories hold the operating system itself — bin holds programs, etc holds configuration files, usr holds installed software. You will rarely need to touch these. The directory you will live in is home, which contains a personal folder for every user on the machine. Your folder — for a user named aditi, that is /home/aditi — is your workspace, and the shell's shorthand ~ always means exactly that folder, no matter who is logged in.

Finding Your Place: pwd, ls, and cd

Three commands let you move around this tree the way your feet move around a building. pwd stands for print working directory — it tells you exactly where you currently are, printed as a full path from the root:

aditi@aici-vm:~$ pwd
/home/aditi

ls stands for list — it shows everything sitting inside your current folder, the way opening a drawer shows you its contents:

aditi@aici-vm:~$ ls
Documents  Downloads  notes.txt  photo.jpg

cd stands for change directory — it moves you into a different folder, just like physically walking into a different room:

aditi@aici-vm:~$ cd Documents
aditi@aici-vm:~/Documents$ pwd
/home/aditi/Documents

Notice the prompt itself changed from ~$ to ~/Documents$ — bash is constantly telling you where you stand, the same way a mall directory sign says "You Are Here." To step back out one level, use two dots, which always mean "the folder directly above this one":

aditi@aici-vm:~/Documents$ cd ..
aditi@aici-vm:~$ pwd
/home/aditi

This is the crucial idea of relative paths versus absolute paths. An absolute path always starts from the root / and describes the complete route, no matter where you currently stand — /home/aditi/Documents means the same thing whether you type it from your home folder or from deep inside /usr. A relative path, like plain Documents or .., only makes sense relative to where you are standing right now — typing cd Documents while inside /usr would fail, because there is no Documents folder there. A single dot, ., means "this exact folder I am in right now" — you will see it used later. Think of an absolute path as full GPS coordinates and a relative path as "turn left from where you're standing" — both get you somewhere, but only one works regardless of your starting point.

Creating, Copying, Moving, and Carefully Deleting

Four commands do the everyday work of managing files. mkdir (make directory) creates a new folder. touch creates an empty new file, or updates an existing one. cp copies a file, leaving the original in place. mv moves a file to a new location — and, cleverly, is also how Linux renames a file, since "renaming" is really just "moving a file to a new name in the same place."

aditi@aici-vm:~$ mkdir project
aditi@aici-vm:~$ touch project/readme.txt
aditi@aici-vm:~$ ls project
readme.txt

aditi@aici-vm:~$ cp project/readme.txt project/readme_backup.txt
aditi@aici-vm:~$ ls project
readme.txt  readme_backup.txt

aditi@aici-vm:~$ mv project/readme_backup.txt project/old_readme.txt
aditi@aici-vm:~$ ls project
old_readme.txt  readme.txt

Trace it step by step: mkdir project creates an empty folder. touch project/readme.txt creates one empty file inside it — notice the path project/readme.txt is a relative path built by joining the folder name and file name with a slash, exactly the way /home/aditi joins home and aditi. cp then duplicates that file under a new name, so now two files exist. mv renames the copy — the file's content is untouched, only its name changes, which is why it still holds zero bytes just like its sibling.

Now the command you must respect: rm (remove) deletes a file.

aditi@aici-vm:~$ rm project/old_readme.txt
aditi@aici-vm:~$ ls project
readme.txt

This is the single most important correction to make early: many students assume rm works like dragging a file to the Recycle Bin on Windows or the Mac trash can — recoverable with a click. It does not. Linux's rm deletes immediately and permanently; there is no bin to fish it back out of. Adding the -r flag lets rm delete an entire folder and everything inside it in one shot (rm -r project would erase the whole project folder), and adding -f forces it to skip any "are you sure?" warnings. The combination rm -rf, pointed at the wrong folder, has permanently destroyed years of work for careless users — including experienced professionals. The rule to internalize now, while the stakes are a homework folder and not a company's server: before you press Enter on any rm command, run ls on that exact same path first, read the output, and only then delete.

Reading a File Without Opening an App

Instead of double-clicking a file to open it in an editor, the shell can print a file's contents straight into the terminal. cat (concatenate) prints the whole file at once. head prints just the first few lines, and tail prints just the last few — useful when a file is thousands of lines long and you only need a glimpse. First, let's build a small file using echo, which simply prints text — and the > symbol, which redirects that printed text into a file instead of the screen:

aditi@aici-vm:~$ echo "Line 1" > poem.txt
aditi@aici-vm:~$ echo "Line 2" >> poem.txt
aditi@aici-vm:~$ echo "Line 3" >> poem.txt
aditi@aici-vm:~$ cat poem.txt
Line 1
Line 2
Line 3

A single > creates the file fresh (or wipes it clean if it already existed) and writes into it — so watch out, using > a second time would have erased "Line 1" and left only "Line 2". That is exactly why the second and third lines use double >> instead, which means append — add to the end of the file, keeping everything already there. Mixing these up is a very common beginner error: one missing angle bracket silently deletes your previous data instead of adding to it.

aditi@aici-vm:~$ head -n 2 poem.txt
Line 1
Line 2

aditi@aici-vm:~$ tail -n 1 poem.txt
Line 3

head -n 2 means "show the first 2 lines"; tail -n 1 means "show the last 1 line." For files too long to fit on one screen, the command less opens the file one screen at a time, letting you scroll with arrow keys and quit with q, without ever printing thousands of lines and flooding your terminal.

Who Is Allowed to Do What: File Permissions

Every file and folder on a Linux system carries a permission label describing exactly who may read it, write to it, or execute it as a program. You can see this label by adding -l (long format) to ls:

aditi@aici-vm:~$ ls -l notes.txt
-rw-r--r-- 1 aditi students 245 Aug 11 09:14 notes.txt

Focus on the ten characters at the very start: -rw-r--r--. The first character describes the type: - for an ordinary file, d for a directory. The remaining nine characters split into three groups of three: permissions for the owner, the group, and everyone else. Each group of three stands for read, write, and execute, in that fixed order, with a dash meaning "not allowed." Reading -rw-r--r--: the owner (aditi) has rw- — read and write, but not execute, which makes sense for a text file. The group has r-- — read only. Everyone else also has r-- — read only. Nobody, including the owner, can "execute" this file, because it is a plain text document, not a program.

To change permissions, the command is chmod (change mode), and the cleanest way to use it is with numbers, not letters. Each permission gets a value: read = 4, write = 2, execute = 1. Add the values you want for each of the three groups, and you get a single digit per group — three digits total. This is worth working through by hand once, since it looks intimidating but is just addition. Suppose you want the owner to have full control (read + write + execute = 4 + 2 + 1 = 7), the group to be able to read and run it but not edit it (read + execute = 4 + 1 = 5), and everyone else the same (4 + 1 = 5). That gives the three digits 7, 5, 5 — written together as 755:

aditi@aici-vm:~$ chmod 755 script.sh
aditi@aici-vm:~$ ls -l script.sh
-rwxr-xr-x 1 aditi students 88 Aug 11 09:20 script.sh

Check the output against the math: rwx for the owner (7), r-x for the group (5, since w is missing), r-x for others (5). The letters and the digits are two notations describing the exact same thing — once you can convert between them in your head, permission errors on real systems stop being mysterious and start being a two-second mental calculation.

Chaining Commands: Redirection and Pipes

You already saw > and >> send a command's output into a file instead of the screen. A related, even more powerful symbol is the pipe, written |, which sends the output of one command directly into the input of another, without ever touching a file in between. This is how small, simple tools combine into something more useful — the Linux philosophy of building complex results from simple building blocks. For example, grep searches text for a pattern and prints only the matching lines. Piped after cat, it filters a file's contents on the fly:

aditi@aici-vm:~$ cat poem.txt | grep "Line 2"
Line 2

Here, cat poem.txt would normally print all three lines to the screen; instead, the pipe hands that output to grep "Line 2", which reads it and prints only the line containing that exact text. Another common tool, wc -l (word count, lines only), counts how many lines it receives:

aditi@aici-vm:~$ cat poem.txt | wc -l
3

Three lines went in, and wc -l reported the number 3. Neither grep nor wc knows or cares where its input came from — a file, another command, anywhere — which is precisely what makes piping so flexible: any command that produces text output can feed any command that accepts text input.

Wildcards: Typing Patterns Instead of Exact Names

Rather than naming every file individually, the shell lets you use the asterisk * as a wildcard meaning "any sequence of characters, including none at all." Listing every text file in a folder, regardless of what each one is called, becomes one short command:

aditi@aici-vm:~$ ls *.txt
notes.txt  poem.txt

The shell expands *.txt before ls even runs, matching it against every filename in the current folder and keeping only the ones ending in .txt — so photo.jpg is correctly left out. A single question mark ? matches exactly one character instead of any number, so doc?.txt would match doc1.txt or docA.txt, but not doc10.txt, since that has two characters where the ? only accounts for one.

Two Traps Worth Naming Directly

Beyond the trash-bin misconception already corrected above, one more habit trips up almost every student switching from a Windows or Android background: Linux commands, filenames, and folder names are case-sensitive. On Windows, typing documents or Documents reaches the same folder. On Linux, they are two completely different names — cd Documents succeeds while cd documents fails with "No such file or directory," even though a human reading both would assume they mean the same thing. The shell does not guess your intent the way a phone's autocorrect does; it matches exactly what you typed, character by character, uppercase and lowercase treated as entirely different letters.

Why This Matters Beyond This Chapter

Every skill practiced here — navigating a tree of folders with exact paths, distinguishing what a file allows versus who is allowed to touch it, combining small tools with pipes instead of writing one giant program — reappears the moment you start real programming. Installing a Python library, saving your code's history with Git, or running a program on a college lab computer or a cloud server all happen through this same shell, using these same handful of commands. Mastering them now is not a detour before "real" computer science; it is the entry ticket to it.

Active Recall: Test Yourself

1. You run pwd and see /home/aditi/Downloads. Which single command takes you to /home/aditi — and is it using an absolute or relative path?
2. A file shows permissions -rwxr--r--. What three-digit number would chmod use to set exactly this permission?
3. You type echo "new score" > scores.txt on a file that already contained five lines of match scores. What happens to those five lines, and how could you have avoided it?
4. Explain, in one sentence, why cd documents might fail even though a folder named Documents genuinely exists in your current directory.
5. What does the command ls *.py | wc -l calculate?

Answer key: (1) cd .. — relative, since it depends on your current location, not a full path from root. (2) 744 — owner reads/writes/executes (4+2+1=7), group reads only (4), others read only (4). (3) The single > overwrites the entire file, erasing all five lines and replacing them with just "new score"; using >> instead would have appended the new line while keeping the old ones. (4) Linux treats filenames as case-sensitive, so documents and Documents are different names, and only the exact match succeeds. (5) It lists every filename ending in .py in the current folder, then pipes that list into wc -l, which counts and prints how many such Python files exist.

Summary

• A terminal is the window; a shell (like bash) is the program that reads and runs your typed commands.
• The Linux filesystem is one tree rooted at /; ~ is shorthand for your home folder.
• pwd shows where you are, ls shows what is around you, cd moves you; absolute paths start from /, relative paths depend on your current location, and .. means "one level up."
• mkdir, touch, cp, and mv create, copy, and rename; rm deletes permanently — there is no trash bin to recover from.
• cat, head, tail, and less read file contents without opening an editor.
• File permissions are three groups of read/write/execute for owner, group, and others; chmod sets them using digits (r=4, w=2, x=1) added per group.
• > overwrites a file, >> appends to it, and | pipes one command's output into another command's input.
• * and ? are wildcards for matching filenames by pattern instead of typing each one out.
• Linux is case-sensitive everywhere — commands, filenames, and folder names.