rpassword

rpassword makes it easy to read a password (or other sensitive input) from a console application in Rust, without echoing it back to the screen. It works consistently across Unix, Windows, macOS, BSD, and WASM by talking directly to the terminal or a configurable input/output target, rather than relying on a single platform-specific API.

Beyond the basic read_password() and prompt_password() functions, a ConfigBuilder lets callers redirect input and output to files, in-memory readers/writers, or a discard target, and choose visual feedback ranging from fully hidden to a mask character or a partial mask. This makes both interactive CLI password prompts and automated tests straightforward to implement with the same API.

What You Get

• read_password() and prompt_password() convenience functions for the common case of hiding input on the current TTY
• A ConfigBuilder for customizing input source (TTY, file path, in-memory data, or any Read implementation) and output destination (TTY, file, writer, or discarded)
• Configurable visual feedback while typing: fully hidden, a repeated mask character, or a partial mask that reveals the first N characters
• Cross-platform terminal handling for Unix (via libc/termios), Windows (via windows-sys console APIs), and WASM, plus graceful handling of non-interactive (piped) input
• Ctrl+C interrupt handling that raises SIGINT and restores the terminal’s original mode, and Ctrl+U/Ctrl+W line-editing shortcuts while typing

Common Use Cases

• Prompting for a password or API secret in a CLI tool without echoing it to the terminal or shell history
• Building login or credential-setup flows for command-line applications, similar to Linux’s getpass() or Python’s getpass module
• Writing automated tests for password-prompting code by feeding in-memory input data and discarding or capturing output instead of touching a real TTY

Under The Hood

Architecture rpassword centers on a RawPasswordInput trait with a single production implementation per target platform (RawModeInput in src/unix.rs for Unix via termios, an analogous struct in src/windows.rs for Windows console APIs, and src/wasm.rs for WASM). The trait’s default read_password method in src/lib.rs implements a shared character-processing loop — Enter, Backspace/Del, Ctrl-U (clear line), Ctrl-W (clear to last space), Ctrl-C (raise SIGINT and abort), Ctrl-D (EOF), and ANSI escape-sequence discarding for arrow keys — so only low-level terminal I/O (read_char, write_output, apply_terminal_configuration) is platform-specific; the higher-level control flow is written once. A Config/ConfigBuilder pair (src/config.rs) abstracts the input source (TTY file path or arbitrary Read) and output destination (TTY file path, arbitrary Write, or a discard sink) as enums, which is what makes the same code path usable for both real terminal prompts and unit tests with in-memory data. Tech Stack The crate is pure Rust (98% of the codebase) targeting the 2024 edition with a 1.85 minimum Rust version, depending on libc on Unix, windows-sys (with a narrow feature set: Console, IO, Storage, Security, SystemServices) on Windows, and rtoolbox (from the same author) for line-fixing, safe string handling (a SafeString type that avoids leaving password bytes in memory longer than needed), and TTY-write helpers; tempfile is a dev-only test dependency. Code Quality Tests are colocated with implementation (#[cfg(test)] mod tests blocks in src/lib.rs and src/unix.rs) plus a dedicated tests/no-terminal.rs integration test, covering CRLF/LF input handling, config-driven file and cursor input, and expected error behavior when a Unix file path doesn’t exist. Deprecated functions (read_password_from_bufread, prompt_password_from_bufread) are kept for backward compatibility but explicitly marked #[deprecated] with migration guidance in their doc comments, and a deny.toml plus GitHub Actions workflow (.github/) suggest dependency and CI hygiene are enforced. API Design The public surface is deliberately small: two zero-config entry points (read_password, prompt_password) for the common case, and two _with_config variants plus ConfigBuilder for everything else, following a consistent builder pattern (input_data, input_reader, input_file_path, output_writer, output_discard, password_feedback_mask, etc.) that reads naturally and is demonstrated directly in module-level doc examples and a matching examples/ directory.