Flyline: A Bash Line Editor Rebuilt with Rust

Why Flyline Replaces Readline in Bash

Flyline addresses a specific problem in interactive Bash: readline provides basic command-line editing, but users who want richer feedback must combine separate plugins, scripts, and prompt utilities. Flyline replaces that editing layer with a Bash loadable plugin and keeps the command shell itself as the execution environment. The README states that Flyline runs in the same process as Bash, so it is not a separate terminal emulator or a replacement for Bash.

The target user is a terminal-oriented Bash user who wants autosuggestions, mouse selection, fuzzy history search, syntax highlighting, bracket and quote completion, and improved tab completion. Flyline also targets users who prefer configuring a modern interface in Rust rather than maintaining several independent Bash extensions. The repository describes Rust as the primary language and ratatui.rs as the rendering technology used to draw the interface.

The scope is narrower than a full shell redesign. Bash still supplies command execution, prompt variables, shell history, and the surrounding terminal session. Flyline changes how keys, prompts, completions, and terminal widgets are presented while the user is entering a command. Existing Bash scripts and command-line workflows can remain central, while the editing surface changes substantially.

Flyline's Editing Architecture and Prompt Data Flow

The visible architecture is a Rust library compiled as a Bash loadable object. The Cargo.toml package defines `flyline`, version `1.9.0`, and sets its library type to `cdylib`. The workspace also contains `flybuffer` and `flycontent`, indicating that terminal buffer handling and content representation are separated into project crates. The README names ratatui.rs as the rendering layer.

Flyline handles input at Bash prompts rather than using a separate graphical application to receive text. Its features operate on the command line as the user types: autosuggestions can propose text, fuzzy search can retrieve history entries, completion can be improved or synthesized through `flycomp`, and widgets can add tooltips or other terminal interfaces. Agent mode is described as assisted command writing, not as autonomous shell execution, so the README does not establish that Flyline runs commands on the user's behalf.

Prompt handling is a concrete part of the design. Flyline documents support for `PS1`, `RPS1`, `RPROMPT`, `PS1_FILL`, `PROMPT_RULER`, and `PS2`. Right-side prompt variables work similarly to Zsh according to the README. Dynamic content and asynchronous widgets are also listed, while `examples/widgets.sh` provides a location for widget configuration. The repository also includes `examples/animations.sh` and documents cursor animations and styles, which depend on terminal rendering capabilities.

Installing libflyline.so and Starting the Tutorial

The quickest documented installation path downloads a release installer and updates `.bashrc`. It does not require `sudo`, according to the README. On macOS, the project first requires a Bash version that supports custom builtins.

source <(curl -sSfL https://github.com/HalFrgrd/flyline/releases/latest/download/install.sh)

After installation, the README directs users to run the built-in tutorial. This is the first real use of Flyline because it exercises the installed Bash loadable and its interactive line editor.

flyline run-tutorial

If mouse capture is undesirable, the documented command disables it.

flyline mouse --mode disabled

For a manually downloaded release, select `libflyline.so` for the system. The README says Linux users will probably want the `gnu` variant unless the distribution uses `musl`, such as Alpine or Chimera. The enable command first tries normal loadable lookup and falls back to an explicit shared-object path.

enable flyline 2>/dev/null || enable -f /path/to/libflyline.so flyline
flyline run-tutorial

The fallback path is required when Bash cannot discover the shared object through `BASH_LOADABLES_PATH`. Bash 4.4 introduced that variable, and Bash 5.2-alpha added a system-dependent default according to the installation notes. The README documents disabling the plugin with `enable -d flyline`.

Configuring Flyline Through Its Built-In Completion Interface

Flyline does not present configuration as a single static file in the README. Instead, it sets up its own tab completion so a user can enter `flyline <Tab>` and browse settings interactively. Commands copied from that interface can be added to `.bashrc` for persistence. This design fits the stated goal of avoiding a collection of unrelated startup scripts.

The available settings cover features that are otherwise separate from ordinary Bash line editing. Examples include autosuggestions, mouse behavior, cursor styles, animations, agent mode, and completion behavior. The repository includes `examples/settings.sh`, `examples/widgets.sh`, `examples/agent_mode.sh`, and `examples/animations.sh`, providing separate starting points for configuration categories.

A concrete prompt configuration can be added to Bash startup files.

PS1='\u@\h:\w$ '

This sets the standard left prompt to the current user and host, the working directory, and a dollar-sign suffix. The README also documents colored and multiline prompt forms. Right-side prompt configuration uses `RPS1` or `RPROMPT`, while `PS1_FILL` fills the space between left and right prompt areas. The README does not provide a complete list of every setting or guarantee that dynamic widgets appear identically in every terminal.

Flyline's Trade-offs and Limits

Flyline's strongest distinction is the combination of line editing, prompt rendering, completion, history search, and terminal interaction inside one Bash plugin. Fuzzy history search is useful for long command histories, while text selection and click-to-move cursor support address terminal workflows that basic readline does not present in the same way. Syntax highlighting, automatic bracket and quote closing, and completion synthesis affect the command before Bash executes it.

The project is not a drop-in improvement for every environment. It requires a dynamically loadable Bash plugin, and the README specifically calls out custom builtin support on macOS. Manual release installation also depends on selecting the correct binary variant. The documentation does not claim support for Zsh, Fish, or shells that do not load Bash shared objects, so users of those shells should not treat Flyline as a cross-shell solution.

Mouse support introduces a choice rather than an unconditional benefit. The README provides `flyline mouse --mode disabled`, which indicates that mouse capture can interfere with a user's terminal workflow. The project also depends on `ratatui`, terminal rendering behavior, and several git-based dependencies in `Cargo.toml`. Automatic completion synthesis through the separate `flycomp` project adds another component, although the README does not state whether it is enabled by default.

Packages, Licensing, and Upgrade Cost

Flyline has several documented installation paths, which affects the work required to receive updates. The `install.sh` path updates `.bashrc` to load the latest version. Homebrew is available on macOS and Linux, Arch Linux has an AUR package, and the Nix flake provides a package, a development shell, and a NixOS module.

brew install bash
brew install flyline

The Homebrew route requires modern Bash on macOS. On NixOS, the documented approach enables `programs.flyline.enable` and loads the exact store path through the module without modifying `.bashrc` or running an installer. Developers can use `nix develop` for the development shell and `nix build .#flyline` to build the package.

The repository identifies GPL-3.0 as its license and also contains `LICENSE-MIT`. The README does not explain which files are covered by which license, so teams should inspect those files and the distribution terms before redistribution.

The last push was on 2026-10-13, and recent releases include v1.9.0 on 2026-09-20, v1.8.0 on 2026-09-09, and v1.7.1 on 2026-08-19. The repository does not provide a compatibility policy, migration guide, or long-term support commitment.

Flyline Compared with ble.sh

The README identifies `ble.sh` as the closest stated comparison. The README describes `ble.sh` as similar to Flyline. Flyline is written in Rust and uses `ratatui.rs`, but no ble.sh feature comparison is provided. It does not provide a feature compatibility matrix.

For a Bash user, Flyline packages its editor as a loadable native plugin and includes its own tab-completion configuration interface. It documents prompt variables such as `RPS1`, `RPROMPT`, and `PS1_FILL`, as well as widgets, animations, mouse behavior, and agent mode. The comparison should therefore be based on terminal workflow and dependency choices, not on a claim that either project is universally better.

An engineer who already has a stable `ble.sh` setup may have reasons to keep it, especially if the existing configuration is not documented as compatible with Flyline. A user seeking a Rust extension point and a single plugin for rich Bash prompt editing is the clearer Flyline audience. The README does not document interoperability between the two editors, so installing both as competing Bash line editors should not be treated as a supported configuration.

Editorial conclusion

Flyline is a reasonable choice for Bash users who want one integrated editor with rich terminal interactions and who accept a Rust-based plugin in their shell startup path. It is less suitable for users who need a minimal readline replacement or who use Zsh, Fish, or unsupported terminal environments. Verify Bash compatibility, the correct Linux or macOS binary variant, mouse capture preference, and the GPL-3.0 licensing implications before adoption. The last push was on 2026-10-13, and the listed release is v1.9.0 from 2026-09-20.

Frequently asked questions

Official sources

1. HalFrgrd/flyline on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases