Foundations · Linux CLI24 min read

Linux & the Command Line

The terminal looks intimidating, but it’s really just a fast text conversation with your computer, and you already understand the ideas behind it.

From your mentor

Don’t memorise commands. Learn the handful of verbs and how to chain them, and the terminal turns from scary into the fastest tool you own. Every server you’ll ever touch is reached this way.

The terminal is just a text conversation with your computer, and you already get the ideas.

In 10 minutes you’ll move around, read files, and chain commands into a one-line superpower. You do NOT need to write scripts or memorize flags yet.

Pick your way in, same idea, 5 doors

It’s a folder of files, but instead of clicking, you type. ls means “what’s here?”, cd means “go into that folder”, cat means “show me this file”. That’s the whole idea, the rest is just more verbs.

Next: the handful of verbs that do most of the work.

It’s a text loop, not magic

The shell does the same four things forever: show a prompt, read your line, run it, print the result. Once you see the loop, nothing is mysterious.

In plain English

Think of it as texting your computer. The $ prompt is it waiting for a message. You type one instruction, press enter, and it texts back, then waits again. That loop is the entire terminal.

Every line you type is read the same way: the first word is the command, and the rest are flags (options, usually starting with -) and arguments (what to act on).

Part	What it is	In `ls -l /etc`
Command	The verb, the program to run	ls
Flag	An option that changes behaviour	-l (long format)
Argument	What it acts on	/etc (the folder to list)

Move around: pwd, ls, cd

The filesystem is a tree of folders. Three commands let you stand somewhere, look around, and walk into another room.

terminal

# the three you'll use a thousand times
$ pwd                 # print working directory (where am I?)
ls -la              # list everything here, including hidden dotfiles
cd ~/projects       # change directory into ~/projects
cd ..               # go up one level
cd -                # jump back to the previous directory/home/you
drwxr-xr-x  4 you you 4096 Jun 20 09:10 .
-rw-r--r--  1 you you  220 Jun 20 09:10 .bashrc

man page: ls

The four path shortcuts that unlock everything

~ is your home folder, . is “right here”, .. is “one folder up”, and / is the root of the whole tree. A path starting with / is absolute (from the root); anything else is relative to where you are now.

Read and shape files

Look inside files without opening an editor, then create, copy, move, and delete them.

terminal

$ cat notes.txt           # dump a whole file
less big.log            # scroll a big file (q to quit)
head -n 20 app.log      # first 20 lines
tail -f app.log         # follow new lines live (great for logs)
mkdir demo && touch demo/hello.txt
cp hello.txt backup.txt
mv backup.txt archive/  # move (or rename)
rm hello.txt

man page: cat

Careful here

One scar everyone earns once: rm has no undo and no recycle bin. rm -rf somedir deletes it and everything inside, instantly and forever. Read the path twice before you press enter, especially with -rf.

Chain commands, the real superpower

Each command does one small thing. The pipe wires them together, and suddenly one line answers questions a GUI never could.

A pipe (|) takes the output of the command on its left and feeds it as the input of the command on its right. Small tools, snapped together like LEGO.

terminal

# how many 404s are in today's access log?
$ cat access.log | grep " 404 " | wc -l37

man page: grep

terminal

# the 5 IPs hitting you the most
$ cat access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -5

man page: sort

Nice, that’s the win

That second line, in one breath, did what a spreadsheet import and a pivot table would take ten minutes to do. This is why engineers live in the terminal.

Operator	What it does	Example
\|	Send output into the next command	ps aux \| grep node
>	Write output to a file (overwrite)	ls > files.txt
>>	Append output to a file	echo done >> log.txt
2>	Redirect errors (stderr)	cmd 2> errors.txt

Permissions: the climb from 777 to least privilege

Every file says who may read, write, and execute it. Beginners make errors vanish with chmod 777, then learn the hard way. Let’s climb it properly.

Each file carries three permissions, read (r), write (w), and execute (x), for three audiences: the user (owner), the group, and others (everyone else). ls -l shows them as -rwxr-xr-x.

chmodthe climb

Rung 0 · Naive
chmod 777: make the error go away
The script won’t run or the upload fails, so you give everyone every permission. The error disappears.
777 means any user on the box can read, modify, AND execute the file. On a shared server or a container, that’s a real vulnerability: a compromised process can rewrite your code or read your secrets. It’s the #1 beginner habit that becomes a breach.
Better
644 for files, 755 for dirs & scripts
Owner can write; everyone else can only read. Add execute (the 5s) for directories you enter and scripts you run.
This is the sane default for almost everything. The owner edits, others read, and nobody can quietly modify your file.
Best practice today
Least privilege + correct ownership
Lock secrets to 600 (owner-only), use chown to give files the right owner, and share via groups instead of opening to others.
Each file grants the smallest access that still works. A leaked or hijacked account reaches only what it truly needs, not the whole machine.

terminal

$ ls -l deploy.sh          # -rw-r--r-- ... not executable yet
chmod 755 deploy.sh      # owner rwx, group/other r-x
chmod 600 secrets.env    # owner read/write only
chown app:app deploy.sh  # set owner and group

man page: chmod

Octal	Means	Use it for
7 = rwx	read + write + execute	rarely, only the owner of a script (700)
6 = rw-	read + write	files the owner edits
5 = r-x	read + execute	directories and scripts others run
4 = r--	read only	files others should only view
644	owner rw, others r	the default for normal files
600	owner rw only	secrets, keys, .env

Why “execute” on a folder is weird but matters

On a directory, the x bit doesn’t mean “run”, it means “may enter / cd into it”. A folder with r but no x lets you list names but not open what’s inside.

Processes & signals

Everything running is a process with an ID. You can list them, watch them, background them, and stop them.

terminal

$ ps aux | grep node      # find a running process + its PID
top                     # live view of CPU/memory (q to quit)
./long-job.sh &         # run in the background, get a job number
jobs                    # list background jobs
kill 4821               # politely ask process 4821 to stop (SIGTERM)
kill -9 4821            # force-kill (SIGKILL), last resort

man page: kill

Signal	How you send it	What happens
SIGINT	Ctrl+C	Interrupt the foreground program (it can clean up)
SIGTERM	kill PID	Polite “please stop”, the default, allows cleanup
SIGKILL	kill -9 PID	Hard stop by the kernel, no cleanup, can corrupt state
SIGTSTP	Ctrl+Z	Pause (suspend) the foreground job

Reach for kill -9 last

kill -9 gives the process no chance to flush files or close connections. Try plain kill (SIGTERM) first, and only escalate if it ignores you.

Interview angle

Linux fluency is assumed for every cloud and DevOps role. Expect a “debug this server from the terminal” walk-through and rapid-fire basics.

Interview angle

“You SSH into a fresh server and the app won’t start. How do you investigate from the terminal?”

How to answer it

Show a calm, ordered method, not random commands. Move from evidence to cause: logs first, then process, port, permissions, and disk.

1Read the logs first: tail -f /var/log/app.log (or journalctl -u app -f) to see the actual error.
2Check the process: ps aux | grep app, or systemctl status app, is it even running or crash-looping?
3Check the port: ss -ltnp to see if something else already holds the port it wants.
4Check permissions/ownership: ls -l on the config and binary, a 600 file owned by root the app user can’t read is a classic.
5Check resources: df -h (disk full?) and df -i (out of inodes?), then free -m for memory.
6Reproduce in the foreground: run the binary directly to see stderr and the exit code immediately.

Green flags

Starts with logs and works toward the cause
Uses pipes (grep, ss) fluently
Mentions exit codes, ownership, and disk/inodes

Red flags

Jumps straight to chmod 777 or sudo everything
Reboots blindly with no evidence
Can’t navigate or read a log without a GUI

Q.chmod 644 vs 755?

A.644 for normal files (owner writes, others read); 755 for directories and scripts (adds execute).

644 (rw-r--r--)

755 (rwxr-xr-x)

No execute bit

Execute for everyone

Use for: text, configs, assets

Use for: folders, runnable scripts

They’re checking: That you don’t reach for 777, and know x on a dir means “enter”.

Q.Pipe (|) vs redirect (>)?

A.| sends output to another command; > sends it to a file.

| (pipe)

> (redirect)

Feeds the next command’s stdin

Writes to a file (overwrites)

ps aux | grep node

ls > files.txt (>> appends)

They’re checking: That you can compose tools, not just run them one at a time.

Q.kill vs kill -9?

A.kill sends SIGTERM (polite, allows cleanup); kill -9 sends SIGKILL (forced, no cleanup).

kill (SIGTERM)

kill -9 (SIGKILL)

Process can flush & exit cleanly

Kernel stops it immediately

Try this first

Last resort, may corrupt state

They’re checking: That you escalate gradually instead of -9 by reflex.

Q.Hard link vs symbolic link?

A.A hard link is another name for the same data; a symlink is a pointer to a path.

Hard link

Symlink (ln -s)

Same inode; survives if original is deleted

Breaks if the target moves/deletes

Same filesystem only

Can cross filesystems, point at dirs

They’re checking: That you understand inodes vs paths, not just “shortcuts”.

Q.How do you find which process holds a port?

A.ss -ltnp (modern) or lsof -i :PORT shows the PID bound to a port.

ss -ltnp lists listening TCP sockets with the owning process.
Then kill that PID, or reconfigure your app to a free port.

They’re checking: That you reach for ss/lsof instead of guessing.

Your turn, in your own terminal

No server or account needed, just the terminal on your own machine. About 15 minutes, and it turns reading into muscle memory.

Now do it in your own account

~15 min $0, it’s your own machine

Open a terminal and work through these in order. Everything happens in a throwaway folder you delete at the end.

Before you start

2 to have ready

A terminal: macOS Terminal, any Linux shell, or Windows WSL (Ubuntu).

echo $SHELL

That’s it, the core tools (ls, grep, chmod, ps) ship with every Unix system.

bash --version

1
Make a throwaway playground and move into it.
Free tier
Your terminal
aws cli
```
$ mkdir ~/cli-playground && cd ~/cli-playground
```
You should see: pwd now prints a path ending in /cli-playground.
2
Create a few files, then list them (including hidden).
Free tier
Your terminal
aws cli
```
$ printf "a\nb 404\nc\n" > access.log && touch secrets.env deploy.sh && ls -la
```
You should see: three files listed, each showing its rwx permission string.
3
Chain commands: count the lines containing 404.
Free tier
Your terminal
aws cli
```
$ cat access.log | grep 404 | wc -l
```
man page: grep
You should see: 1, you just composed three tools into one answer.
4
Lock the secret file down, then prove it.
Free tier
Your terminal
aws cli
```
$ chmod 600 secrets.env && ls -l secrets.env
```
man page: chmod
You should see: -rw------- ... only you can read or write it.
5
Background a process, list it, then stop it.
Free tier
Your terminal
aws cli
```
$ sleep 300 & jobs && kill %1
```
You should see: a job number appears, then it’s terminated, no -9 needed.

Last step: tear it down

Once you’ve seen it work, remove everything so nothing keeps billing.

Delete the whole playground when you’re done.

rm -rf ~/cli-playground

Nothing here costs anything, it all lives on your own machine.

Read the path before any rm -rf, there’s no undo.

Next up

Next, Networking 101

IP addresses, ports, DNS, and how a request actually reaches a server, the next foundation before you touch the cloud.

It’s a text loop, not magic

Move around: pwd, ls, cd

Read and shape files

Chain commands, the real superpower

Permissions: the climb from 777 to least privilege

chmod 777: make the error go away

644 for files, 755 for dirs & scripts

Least privilege + correct ownership

Processes & signals

Interview angle

Your turn, in your own terminal

Now do it in your own account