whoami

whoami is a no_std-compatible Rust crate for pulling identity and environment facts about the machine a program is running on: the user’s real name and username, the device hostname and pretty name, the OS distribution, desktop environment, target platform, and CPU architecture. Every accessor is a plain zero-argument function returning a String/OsString (or an enum for platform, CPU architecture, and desktop environment), so there is no client object to construct or configuration to wire up.

Under the hood it dispatches to a different backend module per target: libc getpwuid/gethostname calls on Unix, objc2-system-configuration on Apple platforms, native Windows APIs, /etc/hostname reads on Redox, web-sys DOM calls in a browser, and WASI or stub fallbacks elsewhere — all behind one consistent API. That breadth of platform coverage, combined with an active MSRV policy and a companion whome CLI binary, is why it has become a standard building block wherever Rust code needs to introspect its runtime environment: telemetry, CLI tools, desktop apps, and diagnostics.

What You Get

• Zero-argument functions for username(), realname(), account(), hostname(), and devicename(), each with an _os() variant returning OsString for non-UTF-8-safe handling
• distro() for a human-readable OS distribution string (e.g. “Fedora 26 (Workstation Edition)” or a parsed macOS product name/version)
• desktop_env() returning a DesktopEnvironment enum (Gnome, Kde/Plasma, Xfce, Hyprland, Niri, Cosmic, Aqua, and more), with automatic None when running over SSH
• platform() and cpu_arch() returning typed Platform and CpuArchitecture enums instead of raw strings, so callers can match exhaustively
• lang_prefs() returning structured LanguagePreferences (language, collation, monetary, messages, numeric, time) parsed from LANG/LC_*/LANGUAGE following the GNU gettext precedence rules
• no_std support with an alloc-only core and an optional std feature, plus WASM targets for both a plain browser DOM backend and a WASI/wasite backend

Common Use Cases

• Populating a default Author or git config user.name fallback in a CLI tool from realname()/username()
• Tagging telemetry, crash reports, or logs with the reporting machine’s hostname, OS distro, and CPU architecture
• Adapting a desktop application’s UI or shortcuts to the detected desktop environment (e.g. GNOME vs KDE keybinding conventions)
• Building a system-info or “about this app” panel that shows platform, architecture, and OS version without shelling out to uname or systeminfo
• Selecting a user’s preferred language/locale for a CLI or GUI at startup via lang_prefs() instead of hand-parsing LANG

Under The Hood

Architecture The crate is no_std at its root (lib.rs) with an alloc-only core, and re-exports a small public surface from api.rs that calls into a Target trait implemented once per platform. os.rs uses #[cfg_attr(..., path = "os/<platform>.rs")] on a single mod stub; declaration to conditionally swap in the real implementation file (os/unix.rs, os/windows.rs, os/redox.rs, os/web.rs, os/wasite.rs, os/daku.rs) at compile time, falling back to os/stub.rs when no target matches — so callers always get a fully implemented Target regardless of platform, and adding a new platform means writing one new backend file. Each public function in api.rs is a one-line #[inline(always)] delegation to Target::method(Os), keeping the platform-dispatch layer completely separate from the public API’s error/string conversion (conversions.rs, result.rs).

Tech Stack Pure Rust with edition 2021 and an MSRV of 1.75, structured as a Cargo workspace (whoami/, example-web/, xtask/). Platform backends pull in target-gated optional dependencies only when relevant: libc for Unix syscalls (getpwuid_r, gethostname, uname), objc2-system-configuration for macOS’s SCDynamicStore, libredox for Redox, web-sys (Navigator/Document/Window/Location) for browser WASM, and wasite for a WASI convention. Feature flags (std, wasi-wasite, wasm-web, force-stub) let consumers opt out of std entirely or force the stub backend for testing.

Code Quality Tests live in whoami/tests/ (lang_parsing.rs, desktop_env.rs) covering the locale-parsing and desktop-environment-matching logic with direct unit assertions; platform-specific backends are exercised primarily through CI running on real target OSes rather than mocked unit tests, and the README documents a manual interactive test procedure for multi-platform changes. Error handling is explicit throughout — a custom Error type wraps std::io::Error (or a Cow<str>-backed equivalent under no_std) with named constructors like missing_record() and empty_record(), and every fallible accessor returns Result rather than panicking. The crate enables an extensive set of #![warn(...)] and #![deny(...)] lints including unsafe_code, missing_docs, and several rustdoc link-correctness lints, and CI runs multiple workflows (ci.yml, new-ci.yml) across targets.

What Makes It Unique Most “who am I” crates on crates.io cover a single OS or a narrow slice of fields; whoami instead maintains one API surface across Linux, Windows, macOS, the BSDs, illumos, Redox, GNU/Hurd, and multiple WASM execution models (plain browser DOM, WASI, and the Ardaku/Daku runtime), each with its own real backend rather than a generic fallback. Its no_std compatibility with only alloc required, combined with typed enums for platform and CPU architecture instead of ad hoc strings, makes it usable in constrained or embedded-adjacent contexts where most equivalent crates assume a full std environment.