# Rustyline for interactive input in Rust command-line programs

> Rustyline is a Rust library for interactive line editing, history, completion, and hints. It fits command-line programs that need editable terminal prompts, with explicit exclusions for Powershell ISE and Mintty.

**kkawakam/rustyline** — Readline Implementation in Rust

- Repository: https://github.com/kkawakam/rustyline
- Website: https://crates.io/crates/rustyline/
- Stars: 1,930 · Forks: 222
- Language: Rust
- License: MIT
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/kkawakam-rustyline

## Rustyline's role in a Rust command-line interface

Rustyline addresses a specific gap between reading one line from standard input and presenting an editable terminal prompt. It is intended for developers building Rust command-line utilities, configuration tools, shells, database clients, and other programs that need users to correct text before submitting it. The README describes Rustyline as a Rust readline implementation based on Antirez' Linenoise, while documenting several additions beyond the limited behavior listed for Linenoise.

The library provides UTF-8 input, word completion, filename completion, history search, a kill ring, multiline wrapping, word commands, and hints. Its key bindings include familiar editing operations such as moving to the start or end of a line, deleting by character or word, clearing the screen, undoing changes, and pasting from a yank buffer. This is useful when a command-line program needs to behave like an established line editor without requiring the application to process every raw terminal event itself.

Rustyline does not define command syntax, parse arguments, validate application-specific input, or render output produced after the prompt. The surrounding program still decides what a submitted line means. Repository examples such as `examples/input_validation.rs`, `examples/sqlite_history.rs`, and `examples/read_password.rs` show areas that developers can integrate with line input, but the README does not fully document those examples or their exact implementation requirements.

It is less appropriate for a utility that only consumes piped text. Standard input is simpler when the program does not require terminal editing, completion, history, or correction before submission. Rustyline becomes relevant when the absence of those features would force users to redo mistakes or make interactive prompts less capable.

## Editing, completion, and history inside Rustyline

Rustyline exposes an interactive editor through a small application-level cycle. A program creates a `DefaultEditor`, passes a prompt to `readline`, receives a `Result`, and decides whether to retain the accepted line. The documented example uses the prompt `>> `. Enter, Ctrl-J, and Ctrl-M finish line entry. Ctrl-C reports interruption, while Ctrl-D reports end-of-file when the current line is empty. Applications must handle these results rather than treating every return value as a completed line.

Editing is stateful. The documented actions include moving the cursor, deleting text, killing text, undoing changes, clearing the screen, and pasting from a yank buffer. Ctrl-R starts reverse history search, Ctrl-S moves forward during that search, and Ctrl-G cancels it. In the default Emacs mode, Up and Down move through matching history entries. These operations belong to the library, so an application can gain interactive correction without implementing a complete terminal editing state machine.

Completion is another part of the interface. The README lists word completion and filename completion. Tab and Shift-Tab navigate completion candidates in the documented key map. A program with no completer can still use `DefaultEditor::new()`, as the README example notes. Hints are also supported, and `examples/diy_hints.rs` exists for applications that need custom hint behavior. The README does not provide the callback signatures required to implement completion or hints, so those details must come from the Rustyline API documentation or repository source.

File history is optional. The README example places `load_history` and `save_history` behind `#[cfg(feature = "with-file-history")]` and uses `history.txt`. The manifest also defines an optional `rusqlite` dependency, while the repository includes `examples/sqlite_history.rs`. These integrations let developers select history storage appropriate to their application, but they require feature and persistence decisions beyond basic line input.

## Installing Rustyline and creating the first prompt

The README directs users to crates.io and gives the following dependency entry for an existing Rust project. The README does not document project creation or provide an exact command for compiling and launching the example.

```toml
[dependencies]
rustyline = "18.0.0"
```

The first real use follows the README example. This setup imports the error type and editor result, creates `DefaultEditor`, conditionally loads `history.txt`, and begins reading from the `>> ` prompt:

```rust
use rustyline::error::ReadlineError;
use rustyline::{DefaultEditor, Result};

fn main() -> Result<()> {
    // `()` can be used when no completer is required
    let mut rl = DefaultEditor::new()?;
    #[cfg(feature = "with-file-history")]
    if rl.load_history("history.txt").is_err() {
        println!("No previous history.");
    }
    loop {
        let readline = rl.readline(">> ");
```

The result handling then distinguishes accepted input, interruption, end-of-file, and other errors. An accepted line is added to in-memory history and printed:

```rust
match readline {
    Ok(line) => {
        rl.add_history_entry(line.as_str())?;
        println!("Line: {}", line);
    },
    Err(ReadlineError::Interrupted) => {
        println!("CTRL-C");
        break
    },
    Err(ReadlineError::Eof) => {
        println!("CTRL-D");
        break
    },
    Err(err) => {
        println!("Error: {:?}", err);
        break
    }
}
```

With file history enabled, the README closes the loop and saves entries to `history.txt`. On a first run with no existing history file, the conditional load reports `No previous history.` The prompt should then display `>> `, accept editable input, print accepted lines as `Line: ...`, and stop when Ctrl-C or Ctrl-D produces the corresponding error.

## Feature flags and the Rustyline upgrade surface

The crate manifest separates some capabilities behind optional dependencies. The `home` package is identified as supporting file completion. `rusqlite` is optional and is configured with the `bundled`, `cache`, `backup`, and `fallible_uint` features for SQLite-backed history. `radix_trie` and `regex` are optional dependencies associated with custom bindings. The workspace also includes the optional `rustyline-derive` package, identified in the manifest as version `0.12.0`.

The README example demonstrates why feature configuration matters. Calls to `load_history` and `save_history` are compiled only when `with-file-history` is enabled. The manifest excerpt does not include the complete feature table, so it does not establish the exact configuration required for every optional dependency. Consumers should inspect the full `Cargo.toml` before selecting features rather than infer the flags from the dependency names.

Upgrade cost also depends on adoption depth. A program that only calls `DefaultEditor::new()`, `readline`, and `add_history_entry` uses a relatively small surface. A program using completion, custom key bindings, SQLite history, password input, or derive support must review more APIs and platform behavior. The repository contains `CustomBinding.md`, `Features.md`, and `History.md`, which are relevant to those decisions, but their contents are not reproduced in the README.

Version selection also needs checking. The README and repository manifest specify `18.0.0`, while the latest listed release is `v18.0.1`, published on 2026-06-24. The documented dependency requirement allows a compatible 18.x selection, but the consuming project's lockfile and resolved dependency version should be checked before deployment.

## Windows terminals impose concrete exclusions

Rustyline supports Unix and Windows, but the supported environments are not interchangeable. The README states that Unix behavior was tested on FreeBSD, Linux, and macOS. For Windows, it lists `cmd.exe` and Powershell.

Two terminal exclusions are explicit. Powershell ISE is not supported, and the README links issue #56 for details. Mintty from Cygwin and MinGW is also not supported. A cross-platform Rust application therefore cannot assume that every terminal bundled with Windows, or every terminal emulator related to Cygwin, provides the same Rustyline behavior.

Highlighting and colors create another boundary. The README says they are not supported on Windows versions earlier than Windows 10 unless ConEmu and `ColorMode::Forced` are used. This affects a feature that might otherwise appear to be controlled entirely by application code. Terminal capabilities and host version must both be considered.

Key bindings also differ by platform. Ctrl-V inserts a special character on Unix but pastes from the clipboard on Windows. Ctrl-Z suspends only on Unix. A project with custom bindings should check these documented differences against the terminals used by its users instead of assuming one cross-platform key map. Repository files `CustomBinding.md` and `examples/custom_key_bindings.rs` provide additional project resources for that work.

## Rustyline, Linenoise, and noninteractive input

Linenoise is the closest documented comparison because the README explicitly identifies it as Rustyline's basis. The documented differences are functional. Rustyline supports Unicode through UTF-8, whereas Linenoise is described as ASCII-only. Rustyline supports word completion, whereas Linenoise is described as supporting line completion only. Rustyline also adds filename completion, history search, a kill ring, multiline support, word commands, and hints.

Plain standard input offers a different design rather than reproducing a line editor. A program can read lines directly when it needs submitted text but does not require cursor movement, inline correction, completion, history search, or key-driven cancellation. That approach keeps the application boundary narrow, which can be appropriate for pipes, scripts, and noninteractive services.

Rustyline is the more capable option when those interactions are part of the user experience. Linenoise remains the relevant comparison for projects choosing between established readline models, but the README does not provide comparative benchmark results or binary-size measurements. It supports a feature comparison, not a performance judgment.

## Maintenance history and MIT licensing

The repository is not archived, and its last push was on 2026-10-12. Its recent releases include `v18.0.1` on 2026-06-24, `v18.0.0` on 2026-03-29, and `v17.0.2` on 2025-10-04. These dates show recent repository and release activity. They do not establish that every future Rust or terminal combination will remain compatible.

An upgrade requires reviewing the exact features used by the application. Changes to editor construction, history storage, custom bindings, hints, or platform-specific behavior can require more review than an unused optional dependency. A team should also compare the selected release against its own lockfile and test the terminals listed in the README.

Both the package metadata and `LICENSE` file identify the project as MIT licensed. Applications distributing Rustyline should inspect the license text and handle applicable attribution and notice obligations. This article does not interpret the license or provide legal advice.

## Conclusion

Rustyline suits a Rust command-line application that needs an interactive terminal interface, particularly when UTF-8 editing, word completion, history search, multiline input, hints, or custom bindings matter. It is a poor choice for Powershell ISE, Mintty, plain piped-input utilities, or Windows versions before Windows 10 when highlighting is required. Before adoption, verify the required Cargo features, test the exact terminal combinations used by users, and check the selected crate version and API surface.

## FAQ

### Which terminals and operating systems does Rustyline support?

The README lists Unix, Windows `cmd.exe`, and Windows Powershell. It says Unix was tested on FreeBSD, Linux, and macOS. Powershell ISE and Mintty are explicitly unsupported.

### How do I add Rustyline to a Rust project?

Add `rustyline = "18.0.0"` under `[dependencies]` in `Cargo.toml`, as shown in the README. The README does not provide an exact build or launch command for the example.

### Does Rustyline support UTF-8, file completion, and persistent history?

The documented feature list includes UTF-8, word completion, filename completion, and history search. File history is conditional on the `with-file-history` feature used around `history.txt` in the README example.

## Sources

- [kkawakam/rustyline on GitHub](https://github.com/kkawakam/rustyline)
- [License: MIT](https://github.com/kkawakam/rustyline/blob/master/LICENSE)
- [Project website](https://crates.io/crates/rustyline/)
- [README](https://github.com/kkawakam/rustyline/blob/master/README.md)
- [Releases](https://github.com/kkawakam/rustyline/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/kkawakam-rustyline