CoursesLinux essentialsThe shell & navigating

The shell & navigating

Where you are, moving around, getting help.

Beginner12 min · lesson 1 of 25

A busy kitchen has a pass: the counter where written orders come in and finished plates go back out. The shell is that pass for a whole computer. You write one line of text, press Enter to hand it over, and the machine goes off, does the work, and hands you back a result. That is where almost all server and DevSecOps (development, security, and operations) work happens. No mouse, no clicking around windows, just typed instructions.

The shell itself is a program: the text interface that reads what you type, finds the right tool, and runs it for you. The most common one is bash (short for Bourne Again SHell, a pun on the older Bourne shell it replaced). Some machines ship zsh (the Z shell) instead, but the everyday moves are identical. When you open a terminal you get a prompt, a short bit of text sitting there waiting for input. Everything higher up the stack (Docker, Kubernetes, a CI pipeline, where CI is short for continuous integration, the automated system that builds and tests your code) comes down to you driving Linux from this exact spot. Get comfortable here and the rest has somewhere solid to stand.

Where you are standing

Before you move, you need to know where you are standing. A Linux system is laid out like an enormous building with rooms inside rooms, and at any moment you are standing in exactly one of them. The command that answers where am I is pwd (print working directory: the folder you are currently sitting in).

~/secopslog — bash
$ pwd
/home/deploy

That line is a path: a set of directions from the front door of the building to the room you are in. The front door is a single forward slash, /, and everything on the machine hangs off it. There are no drive letters like C: to juggle; one tree holds it all. That top folder / is called root. Confusingly, the main administrator account is also called root, and you will meet that second one later. For now, root means the very top of the tree.

Everything is a path

A path can be written two ways, the same way you can give a friend directions two ways. An absolute path spells out the whole route from the front door, like a full postal address: /var/log/syslog. It starts with / and means the same thing no matter where you happen to be. A relative path gives directions from where you are standing right now, like "two doors down on the left": ../config. It does not start with /, so its meaning changes depending on your current room.

Four short names turn up constantly. A single dot . means this room, the directory you are in. Two dots .. mean the room one level up, the parent directory. A tilde ~ is a shortcut for your home directory (your own personal folder, usually /home/yourname), the way the word "home" on a map means wherever you happen to live. And / on its own is the root, the top of the whole tree. Once these click, moving around any Linux box feels the same everywhere, because it is the same everywhere.

The folders a DevSecOps engineer opens first
/etc (configuration)
passwd
the list of user accounts
ssh/sshd_config
the rules for remote logins
hosts
local name-to-address lookups
/home (people)
.ssh/
login keys, private stuff
.bashrc
shell startup settings
.bash_history
what this user typed
/var (changing data)
log/auth.log
who logged in and how
log/syslog
general system events
www/
files a web server hands out
/usr/bin and /bin (tools)
ssh, ls, rm
the actual programs
on your PATH
found by name alone
/tmp (scratch space)
world-writable
anyone can drop files here
common foothold
where malware often lands
Everything hangs off a single root, /. You do not need the whole tree memorized, but these branches come up on almost every machine.

Moving around

To walk into a room, use cd (change directory). Give it an absolute path and it takes you straight there. Then check your work with pwd, which never lies about where you ended up.

~/secopslog — bash
$ cd /var/log # walk to an absolute path pwd # confirm where I landed
/var/log

To see what is in the room, use ls (list). On its own it just prints the names. Ask for the long, detailed view with ls -la and you get far more, including the files that were hiding. The tilde below means "list my home folder from wherever I am standing."

~/secopslog — bash
$ ls -la ~ # long format, including hidden dotfiles
total 40 drwxr-xr-x 3 deploy deploy 4096 Jul 17 09:12 . drwxr-xr-x 3 root root 4096 Jun 2 14:05 .. -rw------- 1 deploy deploy 920 Jul 17 09:15 .bash_history -rw-r--r-- 1 deploy deploy 220 Jun 2 14:05 .bash_logout -rw-r--r-- 1 deploy deploy 3771 Jun 2 14:05 .bashrc -rw-r--r-- 1 deploy deploy 807 Jun 2 14:05 .profile drwx------ 2 deploy deploy 4096 Jul 10 08:33 .ssh

Read that like a detailed inventory instead of just names on the doors. Each line gives the permissions (who is allowed to read, write, or run it), the owner, the group, the size, the date, and the name. Any name starting with a dot is hidden; a plain ls skips it, which is exactly why it matters to you. Attackers love hidden files and hidden folders precisely because a quick look walks right past them. Notice .ssh sitting there with drwx------, meaning only its owner can go in. That folder holds login keys, so if you ever see it readable by others, that is a real problem. And .bash_history is a plain record of commands this account has run, which is a gift to anyone poking around after a break-in.

To get home, cd ~ works, and so does cd with nothing after it. To bounce back to the last place you were, cd - remembers it for you and prints where it sent you.

~/secopslog — bash
$ cd ~ # ~ is home; plain "cd" does the same cd - # jump back to the previous directory
/var/log

When you do not know a command

Nobody memorizes every command and every option, the same way nobody memorizes the manual for every appliance in their kitchen. You look it up. The best part is that Linux keeps the manuals on the machine itself, so this still works on a locked-down server with no internet at all. Three habits make you self-sufficient. The manual, the quick summary, and the question "where does this thing actually live."

~/secopslog — bash
$ man ls # the full manual; press q to quit, / to search
LS(1) User Commands LS(1) NAME ls - list directory contents SYNOPSIS ls [OPTION]... [FILE]... DESCRIPTION List information about the FILEs (the current directory by default). Sort entries alphabetically if none of -cftuvSUX nor --sort is specified.

That LS(1) in the corners is the manual section number, and 1 means "a normal user command." Inside the manual, press / to search and q to quit. When you want something shorter than the full manual, most tools answer --help, a built-in cheat sheet. The vertical bar below is a pipe (it hands the output of one command straight into the next), and head keeps only the first lines so a long summary does not scroll off the screen.

~/secopslog — bash
$ ls --help | head # a short usage summary, first lines only
Usage: ls [OPTION]... [FILE]... List information about the FILEs (the current directory by default). Sort entries alphabetically if none of -cftuvSUX nor --sort is specified. Mandatory arguments to long options are mandatory for short options too. -a, --all do not ignore entries starting with . -A, --almost-all do not list implied . and .. -b, --escape print C-style escapes for nongraphic chars --block-size=SIZE with -l, scale sizes by SIZE; e.g., '--block-size=M'; see SIZE format below

The third habit is asking where a command really lives. When you type ssh (secure shell, the tool for logging into remote machines), the shell does not read your mind; it walks through a list of folders called your PATH and runs the first matching program it finds. which shows you the file it picked. type is even better, because it also tells you whether a name is really a file, or secretly an alias, or a shell built-in.

~/secopslog — bash
$ echo $PATH # the ordered list of folders searched for commands which ssh # which file gets picked? type ssh # richer answer: file, alias, or builtin?
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin /usr/bin/ssh ssh is /usr/bin/ssh

That PATH is a security story hiding in plain sight. The shell checks those folders in order, left to right, and stops at the first hit. If an attacker can drop a fake ls or a fake ssh into a folder that sits earlier in your PATH, then typing the command runs their version instead of the real one, and you would never see the swap. This is why type is worth the extra keystrokes: it tells you the exact file that will run, so you can spot a command that has quietly been replaced.

Finally, the shell keeps a record of what you have done. history prints your past commands, which is handy when you want to rerun something long, and it doubles as an audit trail.

~/secopslog — bash
$ history | tail -5 # the last few commands run on this account
498 cd /var/log 499 ls -la 500 sudo tail -f auth.log 501 cd ~ 502 history | tail -5

That list lives in ~/.bash_history. After an incident, a defender reads it to reconstruct what an intruder touched, in order. Attackers know this too, which is why some of them wipe the file or switch history off entirely to cover their tracks. So both sides care about the same little log for opposite reasons, and a suspiciously empty history on an active account is itself a clue.

The shell does exactly what you typed
There is no "are you sure?" and no recycle bin. rm (remove) deletes right away, for keeps. A stray space is the classic trap, because it splits one target into two: rm -rf /tmp/old clears a single scratch folder, but rm -rf /tmp /old, with a gap after tmp, tells rm to wipe everything under /tmp and then a separate top-level folder called /old. Modern rm does refuse to chew through / itself (a built-in seatbelt called --preserve-root is on by default), so rm -rf / on its own errors out instead of erasing the machine. Do not lean on that guard: it only protects the literal /, not /home or /var, and plenty of other tools have no such seatbelt. Read the whole line before you press Enter, prefer full absolute paths for anything destructive, and go slowest of all when you are logged in as root (the all-powerful administrator account), because root is allowed to delete the system out from under itself.
Quick check
01You start in /var/log, run cd .. and then cd .. again, then run pwd. What prints?
Incorrect — That is where you began; each cd .. moves you up a level, it does not keep you in place.
Incorrect — One cd .. lands here, but you ran it twice, so you kept climbing.
Correct — one step up from /var/log is /var, and a second step up reaches /, the root of the tree.
Incorrect — cd .. always goes to the parent directory; it never jumps to your home. That would be cd ~.
02The lesson says the shell searches the folders in your PATH in order, left to right, and stops at the first match. Why does that ordering turn PATH into a security concern?
Incorrect — the shell stops at the first hit, it does not run every match.
Incorrect — speed is not the issue the lesson raises; the risk is which file gets chosen.
Correct — because search stops at the first match, an attacker just needs their fake to sit earlier in PATH.
Incorrect — you can still run any command by full path, and PATH order, not deletion, is the danger described.
03You are on a server you do not fully trust and want to be sure that typing ls runs the genuine /usr/bin/ls and not something slipped in earlier on your PATH. Which single check answers that most completely?
Correct — the lesson calls type the richer check precisely because it distinguishes file, alias, and built-in and names the file.
Incorrect — man shows documentation, not which file your shell will actually resolve and execute.
Incorrect — --help prints usage, not the resolved path or whether the name is an alias.
Incorrect — history only lists past commands and says nothing about which file runs now.

The first thing to type on any machine you land on is pwd, then ls -la. In two lines you know where you are standing and what is actually in the room, hidden files and all. Run that pair every single time, before you touch anything, and you stop guessing about the ground under your feet.

Try this

Work through “When you do not know a command” yourself on a sandbox you can throw away, following the commands above in order. Then break one step deliberately and re-run, so you have seen the failure before it finds you.

Takeaway

The trap worth remembering here: the shell does exactly what you typed. Check that on your own systems before you need to, because it is cheaper to find on a quiet afternoon than during an incident.

Related