id — Print the current user's UID, GID, and group memberships across all 5 shells
Equivalents in every shell
idPOSIX utility. Bare `id` prints `uid=1000(name) gid=1000(name) groups=1000(name),27(sudo),...`. `id -u` is just the numeric UID (perfect for `if [ "$(id -u)" -eq 0 ]; then ... # running as root`); `id -un` is the username string. `id -G` lists numeric group IDs space-separated; `id -Gn` lists group names.
idSame `/usr/bin/id`. On macOS, supplementary groups can also live in Open Directory (Active Directory bind, network accounts) — `id` reads `/etc/group` AND DSC. `dscl . -read /Users/name` shows the AD attributes if your user is bound to a network directory.
idSame external. Fish has no `$EUID`-style builtin; for "is the user root" use `test (id -u) -eq 0`. The `$USER` variable holds the username, equivalent to `id -un`.
[System.Security.Principal.WindowsIdentity]::GetCurrent()Returns a `WindowsIdentity` object exposing `.Name` (DOMAIN\user), `.User.Value` (SID), `.Groups` (list of SIDs). For HUMAN-READABLE groups: `[Security.Principal.WindowsIdentity]::GetCurrent().Groups | ForEach-Object { $_.Translate([Security.Principal.NTAccount]) }`. Aliases: `$env:USERNAME` for user, `whoami /groups` for groups.
whoami /allBuilt-in. `whoami` alone prints the username; `whoami /groups` lists Windows-side group memberships; `whoami /priv` shows token privileges; `/all` dumps everything. NO concept of numeric UID — Windows uses SIDs (`S-1-5-21-...`) instead, which `whoami /user /fo csv` reveals.
Worked examples
Check if running as root / administrator
[ "$(id -u)" -eq 0 ] && echo "root"[ "$(id -u)" -eq 0 ] && echo "root"([Security.Principal.WindowsPrincipal] [Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltinRole]::Administrator)List the user's group memberships
id -Gnid -Gn[Security.Principal.WindowsIdentity]::GetCurrent().Groups | ForEach-Object { $_.Translate([Security.Principal.NTAccount]) }whoami /groups /fo listGet just the username (no other fields)
id -un$env:USERNAMEwhoamiGotchas
- Linux `id` and macOS `id` differ subtly on supplementary-group ordering. Scripts that parse `id -G` should sort or use `id -Gz | tr "\0" "\n" | sort` before diff'ing across platforms.
- Windows has NO numeric UID — it uses SIDs (security identifiers). Cross-platform scripts asking "what user is this" should compare BY NAME (`whoami` / `id -un`) rather than by ID. The "is admin" check is also fundamentally different: Unix checks `uid==0`; Windows checks group membership in the local Administrators group, which is what `WindowsPrincipal.IsInRole(Administrator)` does.
- `id -a` is a HISTORICAL flag that some BSDs accept; on Linux it's a synonym for bare `id`. Scripts that rely on `-a` for "all info" should just use `id` without flags.
- macOS users bound to Active Directory or Open Directory may have supplementary groups that `/etc/group` does NOT list — `id` reads the Directory Service Cache (DSC) on macOS and shows them, but tools that read `/etc/group` directly (like some legacy `getgrouplist()` callers) will miss them.
- `whoami /groups` on Windows shows only the user's DIRECT group memberships from the access token — it does NOT show nested group memberships unless the token was generated with `tokenGroups` expansion. To enumerate effective AD permissions use `Get-ADUser -Identity $env:USERNAME -Properties MemberOf` (requires RSAT or domain join).