concept Linux & administration
Linux paths: absolute vs relative
An absolute Linux pathname starts at the process root. A relative pathname normally starts at the working directory, unless an API supplies another starting directory.
What it means
A pathname describes how to look for an object; its spelling does not prove that the object exists or is accessible. Separate the starting context from the components that follow it. Slashes separate components, . refers to the current directory and .. refers to its parent.
The practical distinction is dependency: a relative name depends on a starting directory. An absolute name removes that working-directory dependency, but it does not remove dependence on the process’s root, filesystem view or access rights.
Try it
Example — local string interpretation, not a filesystem check. Start with the displayed baseline, then change only Path to interpret to /logs/app.log. Inspect the result and why it changed. Compare with baseline displays the default and current outcomes together. Without JavaScript, the initial example remains readable, but the controls are disabled.
Resolve a synthetic path
Change one condition and inspect the computed result, its cause, and the model boundary.
Lexical components only: no filesystem existence, symbolic-link targets, mount points, directory type or permission checks.
The relative path is appended to the working directory, then dot components are processed in order.
A real symbolic link can change the lookup result; this output is only a string exercise.
| Input | Supplied value |
|---|---|
| Working directory | /srv/site |
| Path to interpret | ../logs/app.log |
Synthetic local learning example. No account, real network, server, filesystem, credential, command or production change is accessed.
About this model
Lexical components only: no filesystem existence, symbolic-link targets, mount points, directory type or permission checks.
These are bounded teaching rules. Actual behavior needs the linked subject specifications and independent observations. The examples are not live checks.
The baseline result is /srv/logs/app.log. The model starts at /srv/site; .. removes the final component site, leaving /srv, and logs/app.log supplies the remaining components. This explains the string result without establishing that any of those directories or files exist.
Keep Working directory at /srv/site. Change only Path to interpret from ../logs/app.log to /logs/app.log.
Reset restores Working directory to /srv/site and Path to interpret to ../logs/app.log, removes input errors and clears the comparison. It preserves your independent choices to open or close FAQ answers and About this model.
How it works
The example uses a stack of text components. For a relative path, it first joins the working directory and pathname. For an absolute path, it uses the pathname alone. It then ignores empty components and ., retains ordinary names, and handles .. by removing the most recent retained component. It cannot remove anything above its modeled root: the separate synthetic input /a/../../b produces /b, regardless of Working directory.
Real Linux lookup does more than cancel text. It walks directory entries, with directory-type and search-permission requirements along the way. A symbolic link can redirect traversal to its target, and a mount point can change the filesystem encountered.
That makes link/.. an important boundary. Real lookup can follow link to a target directory and then resolve that directory’s parent. The string exercise simply discards the name link, without learning its target. Those routes need not reach the same directory. Missing components or denied traversal can also stop real lookup even when the string calculation completes.
Worked example
These are synthetic inputs, not a captured filesystem observation:
| Input | Value |
|---|---|
| Working directory | /srv/site |
| Path to interpret | ../logs/app.log |
Before processing dot components, the joined text is /srv/site/../logs/app.log.
| Stage | Retained path in the lexical model |
|---|---|
| Starting directory | /srv/site |
Process .. | /srv |
Add logs | /srv/logs |
Add app.log | /srv/logs/app.log |
The intermediate /srv explains why the result is not /srv/site/logs/app.log: the parent component is processed before the remaining names are appended.
What changes when the condition changes
Change only Path to interpret to /logs/app.log, keeping Working directory at /srv/site. The result becomes /logs/app.log, rather than the baseline /srv/logs/app.log.
The leading slash selects the process-root model, so the working-directory field is not used. The difference is not caused by a missing directory or a permission check: neither is evaluated. It comes entirely from changing where interpretation begins. Changing Working directory would not affect this absolute-path result.
In practice
For a Linux application’s pathname problem, keep the investigation read-only and limited to the reported pathname and operation on a system and process you are authorized to inspect. Establish the application’s root, working directory and any call-supplied directory context; your interactive shell may not share them.
Then use environment-appropriate read-only inspection to establish the relevant ancestor directories, symbolic-link targets, mount context and access permissions. With the baseline context and ordinary accessible directories, /srv/logs/app.log is the expected lexical interpretation. Actual lookup evidence must still establish what object is reached and whether the application can perform its intended operation.
STOP if you cannot establish the starting context, encounter an unexpected link target or receive a permission denial. Record the unresolved condition rather than treating the normalized string as a diagnosis. Do not rename files, remove links, expand privileges or loosen permissions on the strength of this example. No filesystem changes are part of this check.
Limits and unknowns
This example does not check filesystem existence, symbolic-link targets, mount points, directory types or permissions. A calculated pathname leaves the real lookup outcome unknown. The display also removes an original trailing slash even though real lookup must still meet its directory-resolution requirement.
Each text field accepts up to 160 characters; that is an interface limit, not a Linux pathname limit. An empty Path to interpret is invalid, not shorthand for the working directory. For a nonempty relative path, Working directory must begin with /. For an absolute path, that field is ignored. Invalid input replaces the calculated outcome rather than leaving a previous valid result on display.
All evaluation is local. The scene does not access a real filesystem, run a command, contact a server or change a deployment.
What to carry forward
When an application and your shell disagree about a relative pathname, compare their starting contexts before changing paths or permissions. If those contexts match, investigate actual traversal and access. String normalization can explain the spelling of a path; it cannot establish that the intended object is reachable.
Frequently asked questions
Editorial questions, answered from the sources listed for this article.
Does a leading slash always refer to the host machine’s root?
No. It refers to the root used by that process. A changed process root can change the starting point, and a separate mount namespace can present a different mounted tree. To relate an absolute pathname to the host’s view, you need evidence about that process’s root and mount context.
Can I safely remove every name/.. pair from a real path?
No. Symbolic-link traversal can make the parent differ from the one suggested by the text. Lookup can also fail before reaching .. if name is missing, is not a directory or cannot be searched. Removing the pair may hide that failure. Preserve the original pathname when investigating real behavior.
Why can the same relative name work in a script but not in my shell?
The script file’s location alone does not establish the starting directory. The process’s actual working directory—or a directory context supplied by the call—does. Compare that context with your shell’s, then consider differences in process roots, permissions and traversal. Different success or failure does not by itself prove that the working directory is wrong.
Does a trailing slash prove the object is a directory?
No. A trailing slash imposes a directory-resolution requirement; it does not report that lookup succeeded. This example removes the separator for display without checking the object’s type. Keep the original trailing slash when investigating a real path, because the normalized display no longer expresses that requirement.
Sources & model boundaries
Primary references used for this explanation. The interactive example is an educational model, not a live check.
- Linux path_resolution(7)
DESCRIPTION: starting point, traversal, dot components, trailing slashes. Process-relative roots and path lookup, with symlink and permission qualifications
Checked .
- Linux inode(7)
DESCRIPTION: inode fields and file types. File metadata and distinction between an inode and payload capacity
Checked .