Introduction to Linux for Developers

You don't need to become a system administrator to be productive on Linux. As a developer, you use a surprisingly small slice of it constantly: moving around the filesystem, editing and inspecting files, chaining small tools together, and managing processes. Learn that slice well and the rest you can look up when you need it.

This guide focuses on exactly that daily-use core. Everything here works the same whether you're on a real Linux machine, a container, a remote server over SSH, or WSL on Windows.

The shell and how it thinks

When you open a terminal you're talking to a shell — usually bash or zsh. The shell reads a line, splits it into a command and arguments, runs it, and prints the result. That's the entire model.

A command looks like this:

command --flag argument
ls -l /home

ls is the program, -l is a flag that changes its behavior, and /home is the argument it acts on. Flags usually have a short form (-a) and a long form (--all) that do the same thing.

You navigate a tree of directories. Two paths matter:

• Absolute paths start from the root: /home/you/project.
• Relative paths start from where you are: project/src.

A few shorthands appear everywhere: . is the current directory, .. is the parent, ~ is your home directory, and / is the root of everything.

Moving around and managing files

These are the commands you'll run hundreds of times a day. They're worth committing to muscle memory.

pwd                 # print working directory (where am I?)
ls -la              # list files, including hidden ones, with detail
cd project/src      # change directory
cd ..               # go up one level
cd -                # go back to the previous directory
 
mkdir -p a/b/c      # make directories, parents included
touch notes.txt     # create an empty file
cp file.txt copy.txt
mv old.txt new.txt  # move OR rename
rm file.txt         # delete a file
rm -r folder/       # delete a folder and its contents

rm is permanent — there's no recycle bin. Pause before rm -r, and never run rm -rf / or paste a delete command you don't understand.

To find things:

find . -name "*.js"        # files by name, recursively
grep -r "TODO" src/        # text inside files, recursively

Reading files without opening an editor

Half of shell work is looking at file contents quickly.

cat file.txt          # dump the whole file
less big.log          # scroll a large file (q to quit)
head -n 20 file.txt   # first 20 lines
tail -n 20 file.txt   # last 20 lines
tail -f app.log       # follow a log live as it grows

tail -f is the one you'll reach for constantly when watching an application's logs while it runs. less is the polite way to open anything large — it doesn't load the whole file into your terminal at once.

Pipes and redirection: the real superpower

This is the idea that makes the command line powerful. Each small tool does one job, and you connect them so the output of one becomes the input of the next. The | (pipe) character does the connecting.

# how many .ts files are in this project?
find . -name "*.ts" | wc -l
 
# the 5 largest items in the current folder
du -sh * | sort -h | tail -n 5
 
# every line mentioning "error" in a log, without duplicates
grep -i error app.log | sort | uniq

Redirection sends output to (or reads input from) files instead of the screen:

echo "hello" > file.txt     # write, overwriting the file
echo "more" >> file.txt     # append to the file
command 2> errors.txt       # send error output to a file
command > out.txt 2>&1      # send both normal and error output

Once pipes click, you stop looking for a specialized tool for every task and start composing the small ones you already know. The count example above (... | wc -l) is a pattern you'll reuse for the rest of your career.

Files, permissions, and ownership

Every file has an owner, a group, and a set of permissions for three audiences: the owner, the group, and everyone else. Run ls -l and you'll see it:

-rwxr-xr--  1  you  staff  1024  Jul 8  script.sh

Read that leading block in three chunks of three: rwx for the owner (read, write, execute), r-x for the group, r-- for others. A d at the very start means it's a directory.

Change permissions with chmod. The most common real need is making a script executable:

chmod +x script.sh    # add execute permission
./script.sh           # now you can run it
 
chmod 644 file.txt    # owner read/write, others read-only
chmod 755 script.sh   # owner all, others read/execute

The numbers are octal: read is 4, write is 2, execute is 1, added together per audience. So 755 means 7 (4+2+1) for the owner and 5 (4+1) for group and others.

Ownership is changed with chown, which usually needs elevated privileges via sudo:

sudo chown you:staff file.txt

Use sudo deliberately. It runs a command as the superuser, which means it can also break the system as the superuser.

Processes and what's running

A running program is a process with a numeric ID (PID). You'll want to see what's running and occasionally stop something.

ps aux              # a snapshot of all processes
top                 # live, updating view (htop is nicer if installed)
jobs                # background jobs in this shell

Control processes from the keyboard and the command line:

# Ctrl+C   interrupt the foreground program
# Ctrl+Z   pause it and drop back to the shell
sleep 100 &         # run in the background (note the &)
kill 12345          # ask process 12345 to stop
kill -9 12345       # force it to stop (last resort)

To find the PID of a misbehaving process:

ps aux | grep node

That pattern — list everything, pipe to grep, filter — is how you find almost anything on a system.

Environment variables and the PATH

Environment variables are named values the shell and programs read. You'll meet them constantly in configuration.

echo $HOME          # print a variable
export API_KEY="secret"   # set one for this session and child programs
env                 # list all of them

The most important one is PATH — a colon-separated list of directories the shell searches to find commands. When "command not found" happens for something you just installed, its folder probably isn't on your PATH.

Settings you want to persist go in a startup file like ~/.bashrc or ~/.zshrc. Aliases live there too:

alias gs="git status"
alias ll="ls -la"

Git is a natural companion to all of this; if you haven't set it up yet, see Git and version control.

Common mistakes

• Running rm -rf casually. There's no undo. Read the path twice.
• Reaching for sudo to fix errors. It often just hides a real problem behind superuser power — and can cause worse ones.
• Editing files you don't own with the wrong permissions, then wondering why a service won't start.
• Forgetting quotes around paths with spaces. cd my folder fails; cd "my folder" works.
• Not knowing where you are. Half of shell mistakes are running the right command in the wrong directory. pwd is free.
• Ignoring the manual. man ls and ls --help answer most questions faster than a web search.

Checklist

• Can I move around with cd, ls, and pwd without thinking?
• Do I understand absolute vs relative paths, and ~, ., ..?
• Can I read a permission string like -rwxr-xr--?
• Can I make a script executable and run it?
• Can I chain tools with a pipe to answer a question (e.g. count files)?
• Do I know how to find and stop a running process?
• Do I know what PATH is and why "command not found" happens?

Keep learning

The best way to learn Linux is to live in it. Set yourself a rule for a week: do file management in the terminal instead of the graphical file browser. It'll be slower at first and then suddenly much faster.

Concrete next steps:

• Learn a terminal editor — nano for simplicity, or start on vim if you're ambitious.
• Get comfortable over SSH by renting a cheap cloud server and poking around it.
• Read man pages for the commands you already use; there are always flags you didn't know about.
• Pair this with Git and version control and debugging systematically — the shell is where you'll do most of both.