Linux absolute vs relative paths: Why cd logs differs from cd /logs

Yesterday cd logs worked; today it says the directory does not exist. Before retrying or adding sudo, run pwd. The folder may be fine—you may simply be looking from a different working directory. A path is determined by both its name and where the lookup starts.

Where does a relative path start?

The working directory is the starting point

The shell keeps a current working directory, and pwd prints it. In this example, user is a placeholder account name:

$ pwd
/home/user/project

Linux paths form a tree rooted at /. A leading slash means start from the root. Without one, as in logs, the lookup starts at the current working directory.

From /home/user/project, logs resolves below project; /logs starts at the root and names a different location. An absolute path is not guaranteed to exist merely because its starting point is fixed.

/
└── home
    └── user
        └── project       ← current directory: /home/user/project
            └── logs

Here logs refers to /home/user/project/logs. If you move to /home/user, the same word refers to /home/user/logs instead.

cd logs and cd /logs have different origins

./ explicitly means “from this directory,” so the first two commands are equivalent here. cd /logs ignores the current directory. If /logs does not exist, it fails with “No such file or directory.” An absolute path fixes the origin; it does not guarantee success.

Where are you after cd fails?

Start in project, enter its logs child, and use cd - to return to the previous location:

pwd
cd logs
pwd
cd -
pwd

An illustrative run ends each line with these path components. The temporary parent prefix may differ by machine:

.../project
.../project/logs
.../project
.../project

If cd /logs then fails, pwd still shows .../project. The failed cd has not moved the shell. In a deployment script, stop before later commands run from the wrong directory:

cd "$target_dir" || exit 1

This assumes target_dir was set earlier. Pasting it into an interactive shell can exit that session on failure; while exploring by hand, inspect pwd after cd instead.

.., ~, and - are different destinations

.. expresses a filesystem relationship. - refers to shell history for the previous working directory. ~ is expanded to the user's home. They may happen to produce the same path, but they are not the same rule. Repeating cd - can toggle between two locations.

What should you check after a path error?

1. Run pwd to see the current working directory.
2. Check whether the input starts with /. That decides whether lookup starts at root or here.
3. Use ls or ls -ld to check whether the target directory exists.
4. Quote names with spaces, for example cd "project files".
5. In scripts, test whether cd succeeded before continuing.

“No such file or directory” and “Permission denied” point to different investigations. If a path does not exist, elevated privileges do not create it. If it exists but traversal is denied, inspect the current user and directory permissions.

Key takeaways

pwd tells you where relative lookup begins. cd logs begins there; cd /logs begins at the root. After a failed cd, check pwd rather than assuming the shell moved. In scripts, stop on a failed directory change before subsequent commands run in the wrong place.