Absolute and Relative Paths

Part I · Module 2 · Chapter 2.2 · Absolute and Relative Paths

1. What a Path Is

A path is text that tells a program where to find something in the tree.

That is the whole definition. A path is not a file. It is not a location in itself. It is a piece of text that a program can turn into a location — and the turning is where everything interesting happens.

Here is a path:

/home/engineer/project/rtl/alu.sv

Chapter 2.1 taught how to read it: start at the root, go into home, into engineer, into project, into rtl, and there find alu.sv. Each slash separates one step from the next.

And here is another path:

rtl/alu.sv

Those two name the same file — sometimes. Whether they do depends on something that is not written down anywhere in the second one. This chapter is about that missing piece.

2. The Working Directory, Briefly

To explain the second path, one fact has to arrive now. Chapter 2.3 covers it properly; a single sentence is enough here.

Your shell is always positioned in exactly one directory, called the working directory. Chapter 1.4 printed it with pwd. It is a property of your shell, it has one value at a time, and it can be changed.

That is all you need for this chapter. The working directory is the missing piece that completes a path like rtl/alu.sv.

3. Absolute Paths: Start at the Root

An absolute path starts with /.

/home/engineer/project/rtl/alu.sv
/etc
/tmp
/

Because it starts at the root, an absolute path is complete on its own. It needs no other information. It names the same place:

• no matter which directory you are currently in;
• no matter which user runs it;
• no matter whether it is typed by hand or sitting inside a script somebody runs next year.

The test is mechanical. Is the first character a slash? Then the path is absolute. There is nothing else to check.

4. Relative Paths: Start Where You Are

A relative path does not start with /.

rtl/alu.sv
scripts/run.sh
docs

A relative path is incomplete by design. To turn it into a location, a program takes your working directory and joins the relative path onto the end of it.

That join is the rule, and you can do it on paper:

working directory  +  /  +  relative path  =  absolute path

Worked through, using the project from Chapter 2.1:

working directory:  /home/engineer/project
you write:          rtl/alu.sv
result:             /home/engineer/project/rtl/alu.sv

Nothing clever happened. The two pieces of text were joined with a slash between them. That is genuinely all that "relative" means.

5. The Same Text, Two Different Answers

Here is the consequence, drawn out.

The second row is worth dwelling on, because beginners usually describe it wrongly.

The resolution did not fail. The rule was applied exactly as in the first row and produced /home/engineer/rtl/alu.sv, which is a perfectly well-formed path. What failed came afterwards: there is no rtl directory in /home/engineer, so when the program went looking, there was nothing at that location.

Forming the path and finding the file are two separate steps. Keeping them separate is what lets you debug this class of error in seconds instead of minutes.

6. Watching It Happen

Enough theory. Here is the same thing in a session. ls lists what is in a directory; Chapter 2.4 teaches it properly, and you only need that one sentence to read along.

$ pwd
/home/engineer/project

$ ls rtl
alu.sv  counter.sv

The working directory is /home/engineer/project. The relative path rtl resolved to /home/engineer/project/rtl, which exists, and ls listed its two entries.

Now move up one directory and run the identical command. (cd changes the working directory; again, Chapter 2.4 is where it is taught.)

$ cd /home/engineer

$ pwd
/home/engineer

$ ls rtl
ls: cannot access 'rtl': No such file or directory

Same five characters typed. Different answer.

Read the error with Chapter 1.3's rule: the message begins with ls:, so ls started and ran. The shell found nothing wrong. ls resolved rtl against the new working directory, got /home/engineer/rtl, looked there, and found nothing.

Now the absolute form, from that same new location:

$ pwd
/home/engineer

$ ls /home/engineer/project/rtl
alu.sv  counter.sv

It works, because an absolute path does not care where you are standing.

7. The Failure That Teaches the Rule

The classic version of this error does not look like a path problem at all.

$ pwd
/home/engineer/project

$ ls scripts/run.sh
scripts/run.sh

That worked. Now, an hour later, after wandering into a subdirectory:

$ pwd
/home/engineer/project/sim

$ ls scripts/run.sh
ls: cannot access 'scripts/run.sh': No such file or directory

Nothing broke. Nothing was deleted. The file is exactly where it was. The relative path resolved against /home/engineer/project/sim this time, producing /home/engineer/project/sim/scripts/run.sh, and there is no scripts directory inside sim.

The lesson generalises past this one command. A relative path that worked is not a relative path that works — it is a relative path that worked from a particular place. If you write one down, save it, or paste it into a message, you have to carry the starting point with it or you have communicated half an instruction.

8. Which One Should You Use?

Both. Deliberately, for different jobs.

Prefer a relative path when you are typing interactively, and the thing you want is near where you already are. It is shorter, there is less to mistype, and you are present to see the result immediately.

$ pwd
/home/engineer/project

$ ls rtl
alu.sv  counter.sv

Prefer an absolute path when the location must not depend on the reader. That includes anything you write down for somebody else, anything in a message, and above all anything stored in a file that will be run later without you watching.

The last case is the important one, and it is worth stating plainly even though scripts are a long way off: a saved sequence of commands runs from whatever directory the person who runs it happened to be in. A relative path inside it is therefore a guess about a stranger's location. Module 15 builds scripts knowing this, and Module 20 adds the checks that catch it. The habit starts here.

There is a third option worth naming, because it is what experienced engineers actually do: build the absolute path out of a value, so there is one place to change it. That is Module 10's subject and it needs variables first. For now, notice that the problem exists.

9. Prediction Practice

Resolution is a skill, and skills need repetitions. Work these on paper before reading the answers. The tree is the one from Chapter 2.1:

/home/engineer/project
├── docs
├── rtl
│   ├── alu.sv
│   └── counter.sv
├── scripts
│   └── run.sh
└── sim
    └── logs

For each row, apply the rule — join the working directory, a slash, and the text — then say whether the result exists.

The answers, with the arithmetic shown:

1. /home/engineer/project + docs → /home/engineer/project/docs. Exists.
2. /home/engineer/project + sim/logs → /home/engineer/project/sim/logs. Exists.
3. /home/engineer/project/rtl + counter.sv → /home/engineer/project/rtl/counter.sv. Exists.
4. /home/engineer/project/rtl + scripts/run.sh → /home/engineer/project/rtl/scripts/run.sh. Does not exist — there is no scripts inside rtl. The path formed correctly; the lookup failed.
5. /home/engineer + project/scripts/run.sh → /home/engineer/project/scripts/run.sh. Exists. The same file as row 4 was reaching for, named correctly from a different starting point.
6. The written path starts with /, so it is absolute and the working directory is ignored entirely. It names /home/engineer/project/docs. Exists.

Row 6 is the one to re-read. When a path is absolute, the working directory contributes nothing. Not "less"; nothing.

10. Two Details Worth Knowing

A trailing slash does not change which directory you mean. rtl and rtl/ name the same directory. The trailing form is harmless, and some commands treat it as a hint that you meant a directory rather than a file.

Doubled slashes are collapsed. /home//engineer is treated as /home/engineer. This matters because paths are often built by joining text together, and an accidental extra slash is forgiving rather than fatal. One exception exists at the very start of a path on some systems, and it is not something you will meet in ordinary work.

A path with a space in it needs extra care. my notes.txt is one file name, but Chapter 1.2 showed that the shell splits a line at whitespace, so a command would receive it as two separate words. Writing such a path correctly needs quoting, which is Module 9's whole subject — it is deliberately not taught here. Until then, prefer file names without spaces in anything you create.

11. Misconceptions

"A relative path is a shorter way of writing an absolute path." It is not shorter — it is incomplete. The missing part is supplied by your working directory at the moment the command runs.

"The error means the file is missing." It means nothing was found at the path that was formed. The file may be perfectly present somewhere else. Form the path yourself, then go looking.

"If it worked once it will work again." Only from the same starting point. §7 is this misconception meeting reality.

"Absolute paths are always better." They are better when the meaning must not move. Typed interactively, they are longer, slower and more error-prone, which is its own kind of worse.

"The shell resolves the path before the program sees it." No. Chapter 1.2 showed the shell splitting the line into words and expanding certain characters — but a plain path like rtl/alu.sv is passed through as written. The program receives that text and resolves it against its own working directory. Keeping this straight matters later, when some programs are given a different working directory than your shell.

12. Check Your Understanding

Question 1. Give the one-character test that tells an absolute path from a relative one.

Question 2. Your working directory is /home/engineer/project/sim. You write logs. What absolute path is formed, and does it exist in the example tree?

Question 3. Your working directory is /home/engineer/project/sim. You write /home/engineer/project/docs. What part does the working directory play in forming the result?

Question 4. A colleague messages: "the log is in sim/logs". What single piece of information is missing, and what would you ask for?

Question 5. ls rtl prints No such file or directory, but you are certain rtl exists. Name two commands you would run, in order, and say what each would tell you.

Question 6. You are writing a command into a file that somebody else will run next month, from a directory you cannot predict. Which kind of path do you use, and why does the other kind fail here?

13. Remember

• A path is text that tells a program where to look. Forming the path and finding the file are two separate steps.
• Absolute paths start with / and name the same place from anywhere. The working directory contributes nothing to them.
• Relative paths do not start with / and are completed from your working directory: working directory + slash + relative path.
• The same relative text can name different files at different moments, because the starting point is not written in it.
• A "No such file" error after a relative path is usually a location problem, not a missing file. Run pwd first.
• Relative for typing, absolute for anything saved or sent. A relative path in a file somebody else runs is a guess about where they will be standing.
• A relative path quoted without its starting point is half an instruction.
• A flow script with an absolute path in it works for exactly one person — Chapter 25.5 replaces them with a small agreed set of project variables.

The rule in this chapter used only plain directory names. The next chapter adds the three shorthands — ., .. and ~ — that make real paths short, and explains the one that is not a directory at all.