This is the guide I wish someone had handed me before started learning linux.
Here's the thing nobody tells you early enough: you don't need to know Linux. You need to know about five things, really well. Everything else , the flags you'll forget, the utilities you'll never touch, the man pages that go on for nine screens , you can look up exactly when you need them, which is rarer than you'd think.
Here's your guide, formatted properly in Markdown:
This is the guide I wish someone had handed me before that first session:
- File System
- Permissions
- Piping
- The
grep/awk/sedTrio cron
Get comfortable with these, and you can hold your own in almost any Linux environment you're dropped into.
1. The File System: Knowing Where You Are
Everything in Linux lives on one giant tree, starting at /. No drive letters, no separate universe for each disk , just folders inside folders, all the way down. Once that clicks, navigating stops being scary.
Four commands get you 90% of the way there:
pwd # "where am I, exactly?"
ls -la # what's in this folder, hidden files included
cd ~/projects # go somewhere ("~" always means your home folder)
cd .. # go up one level
cd - # jump back to wherever you just were
Two dots (..) mean "parent folder." One dot (.) means "here." Once those symbols are muscle memory, you can move around almost any filesystem blind.
Small tip that saved me a lot of retyping: cd - toggles between your last two directories , the terminal's version of hitting "back."
2. Permissions: Who's Allowed to Touch What
Every file has an owner, a group, and a set of rules for what each can do: read, write, e*x*ecute. Run ls -l and it's all spelled out:
$ ls -l deploy.sh
-rwxr-xr-x 1 alice staff 312 Jul 21 09:14 deploy.sh
Read that permission string in three chunks of three: rwx (owner), r-x (group), r-x (everyone else). Alice can do anything to it; everyone else can read and run it, but not edit it.
Two commands cover most of what you'll need:
chmod +x script.sh # make it executable
chmod 644 notes.txt # you: read/write, everyone else: read-only
sudo chown alice:staff file # hand ownership over to alice
Those numbers in chmod 644 aren't arbitrary: 4 is read, 2 is write, 1 is execute, added up per group. 644 = read+write for you, read-only for everyone else. 755 = the same, but everyone can also execute it. You'll type these two numbers for the rest of your career , they're worth just memorizing.
The first time I got "Permission denied" running my own script, I felt personally rejected by my own laptop. Turned out I'd just forgotten the +x.
3. Piping: Making Commands Talk to Each Other
This is the moment the terminal stops feeling like a list of commands and starts feeling like a language. The pipe | takes the output of one command and hands it straight to the next.
ps aux | grep python # find python processes
history | tail -20 # your last 20 commands
du -sh * | sort -rh | head -10 # the 10 biggest things in this folder
grep "500" access.log | wc -l # count how many requests failed
Each command does one small thing well. Piping is how you chain those small things into something genuinely useful , without writing a single line of "real" code.
4. grep / awk / sed: Your Search-and-Replace Trio
Three tools, three jobs. Learn the basics of each and you can text-wrangle almost anything.
grep finds lines that match a pattern:
grep "ERROR" app.log # lines containing ERROR
grep -i "error" app.log # same, but case-insensitive
grep -r "TODO" src/ # search recursively through a folder
grep -c "ERROR" app.log # just give me the count
awk pulls out columns:
awk '{print $1}' access.log # first column of every line
df -h | awk '{print $1, $5}' # disk name + percent used
sed finds and replaces:
sed 's/foo/bar/' file.txt # replace the first "foo" per line
sed 's/foo/bar/g' file.txt # replace every "foo"
sed -i.bak 's/staging/prod/g' config # edit in place, keep a .bak copy
You could spend a career mastering each of these. Don't , learn the patterns above and you'll solve 90% of the text-wrangling you'll ever run into.
5. Cron: Getting the Computer to Remember for You
Cron runs commands on a schedule, forever, without you needing to be there.
crontab -e # open your personal schedule
crontab -l # see what's currently scheduled
Each line is five time fields, then the command to run:
* * * * * command-to-run
│ │ │ │ └── day of week (0–6, Sunday = 0)
│ │ │ └───── month (1–12)
│ │ └──────── day of month (1–31)
│ └─────────── hour (0–23)
└────────────── minute (0–59)
A few real examples:
0 3 * * * /home/alice/backup.sh # every day at 3 AM
*/15 * * * * /home/alice/health_check.sh # every 15 minutes
0 9 * * 1 /home/alice/weekly_report.sh # every Monday at 9 AM
One thing that would've saved me a very confusing afternoon: cron jobs fail silently by default. Redirect the output somewhere you'll actually see it:
0 3 * * * /home/alice/backup.sh >> /home/alice/backup.log 2>&1
That's It. Really.
Everything else in Linux , and there is a lot else , you can look up the moment you need it. But the file system, permissions, piping, grep/awk/sed, and cron aren't things you look up. They're things you live in.
Get comfortable with these five. And happy learning ❤️
Top comments (1)
Nice beginner-friendly overview. One thing I’d update is the scheduling section—on many modern Linux distributions, systemd timers are now the recommended alternative to cron because they integrate better with logging, dependencies, and service management. I’d also consider adding find to the list; I probably use it as often as grep.
References: