Pipr: a Rust tool for building shell pipelines with live evaluation

The core idea is seeing the output while you type

Pipr is a commandline pipe-building tool, written in Rust, and the feature that defines it is in the second paragraph of the README. Pipr can automatically evaluate the pipeline you are editing in the background, showing you the results as you go, and the README says this makes writing complex sed and awk chains a lot easier, as you will immediately see what they do.

That is a real improvement over the usual workflow. A sed and awk pipeline is normally written blind, run, look at the error, adjust, run again. The whole loop exists because you cannot see the effect of a change without executing it. Pipr makes execution the default rather than something you opt into.

The autoeval mode is enabled by simply pressing F2, and it runs your command after every keypress. You can also evaluate a command on demand by pressing enter. The textfield behaves as you would expect, with Ctrl+A and Ctrl+E to jump to the start and end of the line, Ctrl+U to clear the whole text-field, and Alt+Enter to insert a newline.

The tool is MIT licensed, the primary language is Rust, the default branch is master, and the last push was on 2026-05-21. The release history is a bit uneven: the tagged releases are v0.0.16 from November 2021, v0.0.15 from October 2020 and v0.0.14 from September 2020, while the manifest declares version 0.1.0. So the crate has moved past its last tag without a new one being cut, and the repository is not archived.

Why bubblewrap is a dependency and not a detail

The README spends a paragraph on the safety question before it gets to any other feature, and the reasoning is worth taking seriously.

Because this could be dangerous, imagine typing rm ./*.txt to delete all text files, but it already being executed at rm ./*, deleting all files in your working directory, Pipr uses bubblewrap to execute your command in an isolated, read-only environment, making it safe to use. The author's own caveat follows: I wont give any guarantees, but you should be good.

The scenario is the real one. A tool that executes on every keypress will, at some point, execute a command that was never meant to be run as typed. In a normal shell you press enter deliberately. In autoeval mode you do not, and the difference between rm ./*.txt and rm ./* is one keystroke.

The Dependencies section states the practical consequence. Pipr uses bubblewrap to execute your command in an isolated environment, preventing most, though maybe not all, dangers like accidentally deleting something while you are typing a command. This means you will need bubblewrap somewhere on your PATH, or you will have to use the unsafe-mode by passing the no-isolation flag.

So the safety property is not optional in practice. Without bubblewrap installed, the only way to run Pipr at all is to turn the isolation off, which is the opposite of what you want in a tool whose main selling point is that it runs things continuously.

Installation is a static binary, an AUR package or cargo

There is a packaging status badge from repology, and three routes in the README.

If none of the listed installation options are available to you, you can simply use the static binary provided on the releases page, and the README says this should work on most unix-based systems. Note that the releases page it links to is on gitlab.com rather than GitHub, which matches the repository origin.

On Arch Linux, Pipr is available on the AUR, and there are two packages, one for the git version and one for a binary:

$ yay -S pipr-git
$ yay -S pipr-bin

For anyone with a Rust setup and cargo installed, the install is:

$ cargo install pipr

The static binary route is the one to consider if you are not on Arch and do not want a Rust toolchain, and the cargo route is the one that will get you the current code.

The Cargo manifest shows what the tool is built on, and the dependency list is a description of the design. crossterm and ratatui with all-widgets for the terminal interface, ansi-to-tui to convert ANSI output into terminal widgets, syntect for syntax highlighting of the output, config with the toml feature for the configuration file, itertools and crossbeam-channel for the internal plumbing, which crate to find the help viewers on your PATH, unicode-width to handle wide characters in the layout, and libc and wait-timeout for the process and timeout handling. The package metadata classifies it as a command-line utility, a development tool and a text editor, which is an accurate description of a pipeline builder with a syntax highlighted output pane.

History, bookmarks and the paranoid history mode

Pipr keeps a history of your commands, through which you can cycle using Ctrl+P and Ctrl+N, and you can look at the whole History by pressing F4.

Then there is the detail that shows the author has actually used the tool. In autoeval mode you are not pressing Enter that often, so pipr might loose some parts of history. If you want to avoid that, you can enter paranoid history mode by pressing F3, in which Pipr will save any command that successfully runs into the history.

That is a real design decision rather than a convenience. The history of a pipeline builder is the history of the things you actually ran, and the autoeval mode would otherwise pollute it with every intermediate state you typed through. Paranoid mode makes the history a record of working commands rather than a record of typing.

Bookmarks are the second half of that. If you really like a command you worked on, you can bookmark it by pressing Ctrl+S, and you can look through all bookmarked commands by pressing Ctrl+B.

The configuration file is stored at ~/.config/pipr/pipr.toml, and you can add your own output-viewers, help-viewers, snippets and much more there, along with settings like enabling autoeval mode by default. There is also a recovery path: if you accidentally removed something from the config, pipr can print out its well-commented default config if you pass it the --config-reference flag.

Snippets, help viewers and output viewers

The snippets system exists because of the same repetition problem the rest of the tool addresses. A lot of times you will type the same things over and over again, for example awk '{print $...}' or sed 's/.../.../g'. By pressing Ctrl+V you can open a menu of all your configured snippets, choose one by pressing its respective key, and it will be inserted at your cursor, placing your cursor where it is supposed to be.

The cursor placement part is what makes it a snippet system rather than a paste buffer. A snippet can specify where the cursor ends up, which is the difference between inserting a template and inserting a template you then have to fix.

The help viewers answer the other recurring problem. Ever worked on a long pipeline and suddenly forgot that one flag you really need? Hover your cursor over the command and press F5, and a menu opens giving you the option of the command's help output or its man page. You can add your own options, for example tldr, in the config file in the [help_viewers] section.

The output viewers are for the cases where the built-in output window is not enough. Press F6 and choose your output viewer, and these are configurable as well, so you can add more specific things like fx.

The [help_viewers] section reference is the marker of a tool that expects to be extended by the person using it, and the config file is where all of that lives.

Output caching is what makes autoeval practical with slow stages

The output caching feature is the one that makes the whole idea workable, and it is easy to miss in a long feature list.

If your command uses the output of a slow command, or maybe the result of a http-request, rerunning that command with every keypress might not be a good idea. So you can hover over any | symbol and press F7 to cache everything up to that pipe. This way it will not be rerun unless you change it.

The README underlines the case that matters: this is especially important if you are using an external API with rate-limiting.

That is a real problem, not a hypothetical. A pipeline like a curl against a rate limited API piped through a jq filter is exactly the shape where autoeval would hammer the API on every keystroke, and the cache makes it safe by freezing everything up to the pipe you point at. Change the part after the pipe and the upstream is not called again.

The other convenience in the same area is tab completion, which the README describes bluntly: Well, pipr has it. Never forget your filenames ever again. It is filename completion rather than full command or flag completion, which is worth being clear about, since the flag help is handled separately by the F5 help viewers.

The Finish hook is the last piece of the workflow. The finish hook, configured in the config file, is a command that will be executed after you close pipr, and will get the finished bash command line piped into stdin. This can be used to pipe your work into xclip, storing it in your clipboard, which makes it possible to quickly paste it into the terminal.

Editorial conclusion

Adopt Pipr if you live in long sed and awk chains and want to see the output change as you type, and you are willing to install bubblewrap so the evaluation is sandboxed. Do not adopt it if you need shell completions inside the pipeline, because the tab completion it offers is filename completion only, and think twice before using the no-isolation flag, since that removes the only protection between a mistyped command and your filesystem. Before you start, check the version you are getting, because the last tagged release is 0.0.16 from 2021 while the manifest says 0.1.0 and the last push was on 2026-05-21.

Frequently asked questions

Official sources

1. elkowar/pipr on GitHub
2. Issues
3. License: MIT
4. README
5. Releases