Skip to content
shellmap

get-location — Print the current directory — pwd equivalent across all 5 shells

Equivalents in every shell

Bashunix
pwd

Builtin. Prints `$PWD` — the logical path (with symlinks unresolved). Pass `-P` for the physical path (canonicalised). The exit status is always 0.

Zshunix
pwd

Builtin. Same `-L` (logical, default) / `-P` (physical) flags as bash. The special parameter `$PWD` is updated atomically by `cd`, so `${PWD:A}` resolves symlinks without forking.

Fishunix
pwd

Builtin. `pwd -P` for physical path; `pwd -L` for logical (default). Also exposed as `$PWD`; the abbreviation hook can rewrite long paths to `~/…` for prompt display.

PowerShellwindows
Get-Location

Aliased as `pwd`, `gl`. Returns a `[PathInfo]` object — `.Path` is the string, `.Provider` is the PowerShell provider (FileSystem, Registry, Certificate). For just the string, use `(Get-Location).Path` or the automatic variable `$PWD`.

cmd.exewindows
cd

cmd has no separate `pwd` — bare `cd` (no arguments) prints the current path. Inside batch files, `%CD%` is the equivalent variable. Both forms always reflect the file-system path (no provider concept).

Worked examples

Print the current working directory

Bash
pwd
PowerShell
Get-Location
cmd.exe
cd

Capture cwd into a variable

Bash
here=$(pwd)
Fish
set here (pwd)
PowerShell
$here = (Get-Location).Path
cmd.exe
set here=%CD%

Resolve symlinks in the cwd path

Bash
pwd -P
Zsh
echo ${PWD:A}
PowerShell
(Resolve-Path .).Path

Gotchas

  • `Get-Location` returns a `[PathInfo]` object — string-comparing it directly (`(Get-Location) -eq 'C:\foo'`) compares the type-coerced `.ToString()`, which usually works but is surprising. Pull `.Path` explicitly for safety: `(Get-Location).Path -eq 'C:\foo'`.
  • `$PWD` is the same `[PathInfo]` value — assigning `$PWD = 'C:\bar'` does NOT change directory (it shadows the variable in the current scope). Use `Set-Location` to actually change cwd.
  • Inside a non-FileSystem provider (registry, cert), `Get-Location` still returns sensibly — e.g. `Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\Software`. Scripts that pass `(Get-Location).Path` to file APIs blow up when the user is `cd`'d into the registry.
  • On Windows, `Get-Location` preserves the user's drive-letter casing as typed (`C:\` vs `c:\`); on Linux/macOS pwsh, the path is always returned with the OS-native casing. Don't rely on the case for equality comparisons.
  • `pwd` (the alias) is shadowed by the system binary `/bin/pwd` on Linux/macOS pwsh hosts only if you call it via `& pwd` (forces external lookup). Bare `pwd` always resolves to the alias first — same behaviour as the Windows `cd` shadowing.

WSL & PowerShell Core notes

pwsh`Get-Location` is identical on every pwsh platform. The returned `[PathInfo]` always uses the OS-native separator (`\` on Windows, `/` on Linux/macOS) — for cross-platform scripts that build paths, use `Join-Path` instead of string concatenation. The `pwd` alias is unique to pwsh and does NOT shadow the system binary; explicit `& /bin/pwd` reaches the Unix tool.
WSLInside WSL bash, `pwd` returns the Linux path (`/mnt/c/work` for a Windows-side directory). From Windows-side pwsh inside a `\\wsl$\Ubuntu\…` location, `Get-Location` returns the UNC form. To translate between the two forms, use `wslpath -w "$(pwd)"` (Linux → Windows) or `wsl.exe wslpath "$((Get-Location).Path)"` (Windows → Linux from pwsh).

Related commands