whoami — Print the effective username of the current process across all 5 shells
Equivalents in every shell
whoamiExternal binary from coreutils. Prints the effective UID's username (post-`sudo` / `setuid`), NOT necessarily the login user. For the login user use `logname` or `$SUDO_USER`. `id -un` is the POSIX-portable equivalent; `id -u` for the numeric UID.
whoamiSame coreutils binary on Linux; macOS ships its own BSD `whoami` with identical output. The shell variable `$USER` is set by login (`getlogin(3)`) and survives `sudo -E`, so `echo $USER` after `sudo -E zsh` still shows your original username, while `whoami` shows `root`. Use the right one for what you actually want.
whoamiSame external. Fish also exposes `$USER` (login name) and `$EUID` (effective UID). For scripts that need to know "am I root right now", `test (id -u) -eq 0` is the cleanest test — works in every Unix shell.
$env:USERNAMEPure-PS access via env var — no spawned process. The Windows binary `whoami.exe` also works (`whoami` resolves to it) and prints `DOMAIN\user`. For just the username without domain: `[Environment]::UserName`. For full identity including SID + groups: `[Security.Principal.WindowsIdentity]::GetCurrent()`.
whoamiWindows builtin since XP (ships in every Windows install). Prints `domain\user` (lowercase). `whoami /upn` prints the User Principal Name (`[email protected]`) on domain-joined machines; `whoami /fqdn` the full distinguished name; `whoami /all` dumps username + SID + groups + privileges in one go (the Windows equivalent of Unix `id`).
Worked examples
Print the current effective username
whoamiwhoamiwhoami$env:USERNAMEwhoamiTest "am I root / admin"
[ "$(id -u)" -eq 0 ] && echo roottest (id -u) -eq 0; and echo root([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)net session >nul 2>&1 && echo admin || echo not-adminDump full identity (UID + groups + privileges)
idwhoami /allwhoami /allGotchas
- `whoami` reflects the EFFECTIVE UID, not the LOGIN UID. Inside `sudo`, `whoami` says `root`; `$SUDO_USER` (set by sudo) and `logname` say your real user. A script that "logs who ran it" must use `$SUDO_USER` first and fall back to `$USER` / `whoami` only if it's unset — otherwise audit logs blame `root` for everything.
- On Windows, `whoami.exe` lowercases its output (`mycorp\alice`), but `$env:USERNAME` preserves whatever case the login used (`alice` typically, but can be `Alice` on machines where the account was created with mixed case). Don't string-compare the two without `.ToLower()` first.
- In containers (Docker, podman), `whoami` may fail with `whoami: cannot find name for user ID 1000` if the container image has no matching `/etc/passwd` entry for the UID your host user maps to. The container is fine — only the username lookup fails. Use `id -u` for the numeric UID in scripts so the failure mode is "no name" rather than "crash".
- PowerShell `$env:USERNAME` is a string env var — pure read, no syscall. `[Environment]::UserName` is the same thing via the .NET API. They differ from `whoami.exe`: the env var omits the domain prefix, `whoami.exe` includes it. Pick the right one for your downstream consumer (a `Get-ADUser -Identity $env:USERNAME` works; a `Get-ADUser -Identity (whoami)` does not — the backslash trips the parser).
- On `su -` and `runas`, the new shell's `$USER` is updated to the new identity (login shell semantics). On bare `su` (no `-`), `$USER` is sometimes left as the original user depending on the distro — another reason scripts should rely on `whoami` / `id -un` for "who am I right now" rather than env vars.