pwd

What it does

pwd ("print working directory") prints the absolute path of the directory the current shell session is in. It's one of the simplest commands available, but it's essential for confirming your location before running path-sensitive or destructive commands.

Beginner examples

• pwd — print the current directory's full absolute path
• cd /var/log && pwd — confirm you actually landed where you intended after cd
• pwd -P — print the path with all symlinks resolved to their real targets
• Use it inside scripts to capture the starting directory: START_DIR=$(pwd)

pwd

Advanced examples

• Capture the working directory to return to it later in a script: START_DIR=$(pwd); cd /tmp; ...; cd "$START_DIR".
• Compare logical vs physical location when navigating through symlinks: cd /var/symlinked-dir && pwd (shows the symlink path) vs pwd -P (shows the real path).
• Use in a shell prompt or script to dynamically reference the current location without hardcoding paths: cp file.txt "$(pwd)/backup/".
• Combine with cd -P for a fully resolved change of directory followed by a confirming physical pwd.

cd /var/log && pwd -P

Common mistakes

• Assuming pwd and pwd -P always print the same thing — they diverge whenever any component of the path traversed to reach the current directory is a symlink.
• Hardcoding relative paths in scripts instead of anchoring them with $(pwd) or an absolute path, causing scripts to behave differently depending on where they're invoked from.
• Forgetting that cd-ing via a relative path can leave pwd's logical view referencing a symlink chain that doesn't match the real filesystem structure shown by ls -li or readlink -f.
• Not realizing $OLDPWD and $PWD environment variables already hold this information without needing to shell out to pwd repeatedly in scripts.

Tips

• Use pwd -P (or cd -P then pwd) when debugging symlink-related confusion, such as a build tool behaving differently depending on which symlink path was used to enter a directory.
• In shell scripts, prefer the $PWD environment variable over calling out to pwd when you just need the current directory's value without spawning a subshell.
• Combine pwd with cd "$(dirname "$0")" patterns in scripts to reliably locate the script's own directory before doing relative-path operations.

Best practices

• Always confirm your location with pwd before running destructive commands like rm -rf with relative paths, especially over SSH sessions where you might be in an unexpected directory.
• In automation and CI scripts, capture and restore the working directory explicitly (OLDDIR=$(pwd); ...; cd "$OLDDIR") rather than assuming subsequent steps run from the same place.
• Use pwd -P when writing scripts that must resolve real filesystem locations (e.g. for logging, auditing, or deduplication) rather than symlink-based logical paths.

Real-world use cases

• Double-checking your location on a remote SSH session before running rm -rf ./* to avoid deleting the wrong directory.
• Debugging why a build script behaves inconsistently depending on whether it was invoked through a symlinked path versus the real directory.
• Capturing a starting directory in a deployment script so it can safely return there after cd-ing elsewhere to perform steps.

Common interview questions

• What's the difference between pwd and pwd -P? pwd (or pwd -L) shows the logical path as navigated, which may include symlinks; pwd -P resolves all symlinks and shows the real physical path.
• Why might pwd show a path that doesn't match what ls -li reveals about the directory's real location? Because the shell tracked a logical path through a symlink; pwd -P or readlink -f would reveal the true, resolved path.
• How would you safely reference the current directory inside a shell script? Use the $PWD environment variable or capture $(pwd) into a variable, rather than assuming a fixed working directory across invocations.