Absolute vs Relative Path Made Easy

Have you ever run cd reports successfully, only to get "No such file or directory" when you run the same command from another folder? The reason is simple: Linux handles absolute and relative paths differently. Once you understand how each one works, navigating the filesystem becomes much easier and path-related errors are easier to avoid.

This distinction becomes especially important in scripts and automated jobs. A relative path depends on the directory where a command starts, while an absolute path points to a fixed location. A script that works perfectly when you run it manually can fail when cron or another service runs it from a different directory.

In this guide, you'll learn how absolute and relative paths work, when to use each one, and how to check where you are in the filesystem. You'll also see practical examples with pwd, realpath, cd, and other common Linux commands.

Examples

An absolute path is a full address. It always starts at the root of the filesystem, that single / at the very top, and spells out every folder you'd need to pass through to reach a file, no matter where you're currently sitting in the terminal. A relative path, on the other hand, is directions from wherever you happen to be standing right now.

Think of it like giving someone your location. "123 Main Street, Springfield" works no matter where the other person is starting from, that's an absolute path. "Two blocks down, turn left" only makes sense if you're both starting from the same spot, that's relative. Neither one is better on its own, they're just built for different jobs.

Every time you run ls, cd, cp, or open a file in a text editor, you're feeding it one of these two path types whether you notice it or not. Getting comfortable telling them apart at a glance is what stops half the "file not found" errors before they happen. If the bigger picture of how directories nest under root is still fuzzy, our Unix file system guide is worth a read alongside this one.

The rule Linux actually uses is simple: if a path starts with a forward slash, it's absolute. Anything else is treated as relative to your current working directory, whatever that happens to be at that moment.

That output from pwd (print working directory) is an absolute path. Every relative path you type is silently measured from that exact spot. So cd projects means "go into projects, starting from /home/linuxteck." Change your current folder, and that same relative command now points somewhere completely different. This is a good moment to get comfortable with how the Linux file system is structured from the ground up, since paths only make sense once the hierarchy does.

Before you type any path, it helps to confirm your starting point. This is the single habit that prevents most path confusion.

You're in /home/linuxteck/projects and want to get into a subfolder. No need to spell out the whole address.

Pair this with ls once you land in a new folder to confirm what's actually there before you go typing more paths blind.

Doesn't matter how deep you've wandered into the filesystem, this always works the same way.

Same destination, but written so it works from literally anywhere, including from inside a script you don't fully trust yet.

You can chain .. to hop up several levels at once instead of running cd .. over and over.

Each .. steps up exactly one level: the first gets you out of img into assets, the second out of assets into website, the third out of website into projects. Three dot-dot segments, three levels up, landing back at ~/projects. If you'd rather see the whole nested structure at once instead of climbing it blind, the tree command lays it out visually in one shot.

When you're not sure exactly what a relative path points to, realpath will tell you the full truth.

You can point find at "." to search everything under your current folder without typing the full location.

If you want a broader introduction to searching by name, type, or modification time, the find command guide covers it in more depth.

Cron jobs start from your home directory ($HOME) by default when they run from your personal user crontab, not from wherever you happen to keep your scripts. System-level cron jobs, the ones in root's crontab or dropped into /etc/cron.d, commonly start from / instead. Either way, if your script lives somewhere else and you lean on relative paths inside it, cron will look for those relative files starting from the wrong place and come up empty. This is the exact mistake I mentioned earlier.

Both sides of a command can be relative at once, as long as you're clear on what they're relative to.

This is basically a rebuild of the exact bug that once quietly wrecked my backup job for three days straight.

If you want to go deeper into building scripts that survive being run from anywhere, our first bash script walkthrough and the guide on how bash actually looks up commands are good next stops. If that if check on the array length above looks unfamiliar, our guide to bash conditional statements breaks that syntax down.

Nobody thinks about paths until something breaks in exactly the wrong moment. A deploy script that worked fine on your laptop suddenly can't find its own config file on the server. A cron job silently fails at 2am because the working directory it assumed just isn't there when systemd launches it. The command was never wrong, the assumption about where it would be run from was.

Once you actually internalize that a relative path is a promise about your current location, and an absolute path makes no such promise at all, you start writing scripts differently. You stop typing cd .. chains and start reaching for realpath or $(dirname "$0") without thinking twice. That single habit shift is one of the more reliable signs that someone has moved from copying commands to actually understanding the filesystem underneath them, and it's the kind of thing you'll notice matters more, not less, as you move into managing production servers where you don't always control the working directory a job starts from.

It also changes how you read documentation. Man pages and reference material lean on this distinction constantly without spelling it out, and understanding it makes the rest of the filesystem, including things like how realpath resolves symbolic links, click into place a lot faster.