# teip: masking tape for a text pipeline

> teip is a Rust filter that selects a range of its standard input and hands only that to the command you care about, so sed, date, tr and grep keep doing one thing each. It is installed with a package manager or cargo, and its selection modes cover patterns, characters, lines, fields and helper command output.

**greymd/teip** — Masking tape to help commands "do one thing well"

- Repository: https://github.com/greymd/teip
- Stars: 595 · Forks: 18
- Language: Rust
- License: MIT
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/greymd-teip

## Select first, transform second

teip describes itself as masking tape to help commands do one thing well, and that metaphor explains the design in one line. Standard command line tools are specialists. sed replaces. tr translates. date parses. grep selects. When a task needs selection and transformation, you either write a small program, or you pipe, and the pipe loses the context the next tool needs.

teip sits in the pipe as the selection stage. It takes your input, works out which part of it you care about, and passes exactly that part to the command that follows the -- separator. The command then does its one job on a smaller piece of the data.

The examples in the README show the range of jobs. Converting timestamps in /var/log/secure to UNIX time selects the first fifteen characters and pipes them to date.

```bash
$ cat /var/log/secure | teip -c 1-15 -- date -f- +%s
```

Replacing WORLD with EARTH on lines containing HELLO selects matching lines and pipes them to sed.

```bash
$ cat file | teip -g HELLO -- sed 's/WORLD/EARTH/'
```

Uppercasing the second field of a CSV uses the CSV aware field selection.

```bash
$ cat file.csv | teip --csv -f 2 -- tr a-z A-Z
```

And editing the second, third and fourth fields of a TSV file uses a regular expression delimiter.

```bash
$ cat file.tsv | teip -D '\t' -f 2-4 -- tr a-z A-Z
```

The pattern here is consistent: teip decides what to show, the command after the separator decides what to do with it, and neither has to know about the other.

## Five ways to select a range

The usage summary is the densest part of the README, and it is worth reading as a table of selection methods.

```
USAGE:
  teip -g <pattern> [-Gosvz] [--] [<command>...]
  teip -c <list> [-svz] [--] [<command>...]
  teip -l <list> [-svz] [--] [<command>...]
  teip -f <list> [-d <delimiter> | -D <pattern> | --csv] [-svz] [--] [<command>...]
  teip -e <string> [-svz] [--] [<command>...]

OPTIONS:
    -g <pattern>        Act on lines that match the regular expression <pattern>.
        -o              -g acts on only matched ranges.
        -G              -g interprets Oniguruma regular expressions.
    -c <list>           Act on these characters.
    -l <list>           Act on these lines.
    -f <list>           Act on these white-space separated fields.
        -d <delimiter>  Use <delimiter> for the field delimiter of -f.
        -D <pattern>    Use regular expression <pattern> for the field delimiter of -f
        --csv           -f interprets <list> as field numbers of a CSV according to
                        RFC 4180, instead of whitespace separated fields.
```

The five modes are pattern matching with -g, character ranges with -c, line numbers with -l, field numbers with -f, and an external helper with -e. The -e mode is the unusual one: it executes a string in another process that receives identical standard input as the main teip command, and emits numbers that are used as line numbers for actioning. That is how a context window is expressed, by running grep with context flags and letting it report the line numbers.

```bash
$ cat access.log | teip -e 'grep -n -C 3 hello' -- sed 's/./@/g'
```

The -A, -B and -C options are documented as aliases of -e 'grep -n -A <number> <pattern>' and its siblings, so the familiar grep context flags exist in a shorter form.

## Flags that change how the command is run

Beyond selection, a set of flags changes the execution model, and they are the difference between teip as a filter and teip as a small pipeline engine.

The -s flag executes a new command for each actioned chunk, so instead of one long lived child process you get one process per selected range. The --chomp flag makes the command spawned by -s receive the standard input without trailing newlines, which matters when the command is line oriented.

The -I flag takes a replace string and replaces it with the actioned chunk in the command, which implies -s. That is a templating mechanism: the command line itself becomes a function of the data.

The -v flag inverts the range of actioning, and the -z flag makes the line delimiter NUL instead of a newline, which is what you want for binary-ish or record-oriented data. -h prints help information and -V prints version information.

Taken together these cover a lot of ground that in shell usually means writing a loop. The design point is that the transformation command stays a normal command, so it can be anything on your system, and teip handles the part that is fiddly.

## Installing with a package manager or cargo

Installation covers macOS on x86_64 and ARM64, Linux on x86_64 or ARM64 depending on the package source, and there is a Windows installer for x86_64.

On macOS and Linux, Homebrew is the short path.

```bash
brew install teip
```

On Linux there are four package flavours, and the same URL appears under each of them.

```bash
wget https://github.com/greymd/teip/releases/download/v2.3.3/teip-2.3.2.$(uname -m)-unknown-linux-musl.deb
sudo dpkg -i ./teip*.deb
```

The apt, dnf and yum variants use the same download with their own installer command, and the rpm variant points at the.rpm file. The README also asks you to check the hash value from the latest release page if necessary, and says that files whose filenames end with sha256 have hash values listed.

One detail in those URLs is worth flagging rather than repeating blindly. The release path says v2.3.3 while the file name says 2.3.2, so a scripted install copied from the README may 404. Checking the release page before automating it is the sensible move.

For other architectures, the README says to check the latest release page for executables, and if none is present, to build from source with cargo.

```
cargo install teip
```

The optional Oniguruma regular expression support, which the -G flag selects, is a build feature rather than a runtime package.

```bash
### Ubuntu
$ sudo apt install cargo clang
$ cargo install teip --features oniguruma
```

The Red Hat base and the Windows PowerShell with chocolatey variants follow the same shape, installing cargo and clang first, with llvm through choco on Windows.

## The performance claim and how the threads work

The README makes a performance argument, and it makes it in a form you can check rather than in a form you have to trust.

The comparison given is the processing time to replace approximately 761,000 IP addresses with dummy ones in a 100 MiB text file, with the chart on the project wiki and the details in the wiki's Benchmark page. The claim is not that teip is fast in the abstract but that it is fast in the same terms as the tools it wraps. The stated reasoning is that if general UNIX commands in your environment can process a few-hundred MB file in a few seconds, then teip can do the same or better performance.

The mechanism behind that is described in the features list. The targeted command's standard input and output are written to and read from by multiple teip threads asynchronously. So teip is not reading the whole file, buffering a selection and then writing it. It streams, and the child process runs concurrently with the selection logic.

That design is what makes the tool usable on large logs, which is the case the examples are drawn from: /var/log/secure and access.log. A log rotation on a machine that no longer has a shell pipeline budget is exactly where an extra process and an extra copy of the data start to hurt.

The Rust implementation is where the streaming lives. The crate is edition 2018, with serde, regex, log, env_logger, lazy_static, structopt and cfg-if as dependencies, and the optional onig crate pinned to a specific git revision with a patch entry in the manifest. The comment on that patch explains it is a workaround for a build failure in the upstream crate, kept until a new onig release is published.

## Where teip is the wrong tool

The first case is a pipeline that is already simple. If a single awk program or a single sed expression does the job, teip adds a process to the chain, a second thing to learn, and another layer between you and the data. The tool pays off when selection and transformation are genuinely separate problems.

The second case is work that belongs in a program. teip is a filter that runs other commands. If the transformation needs state, error handling, multiple passes or a data structure, then the language you would write it in is the right place, and teip is scaffolding around a program you were going to write anyway.

The third case is a build environment where the Oniguruma mode is needed but no C toolchain is available. The -G flag interprets Oniguruma regular expressions, that support is an optional cargo feature, and enabling it requires the libclang shared library, so the README asks you to make sure it is present. A static binary from the release page is the simpler route.

The alternative is worth naming precisely, because it is not a different tool but a different arrangement of the same tools. The classic shell approach is one program that both selects and transforms, such as awk with a condition and an action, or sed with an address. The teip approach splits the same problem into a selection stage and a transformation stage, which means the transformation can be any command, including one you already use, and the selection semantics are uniform across patterns, characters, lines, fields and helper command output. Whether that separation is worth a process depends on how often you would otherwise be writing a throwaway program.

## Conclusion

teip suits a shell user who keeps reaching for a one-off awk or sed program to select a range of lines, characters or fields before transforming them, and who would rather reuse the standard tools than write another script. It does not suit a workflow that is already expressed cleanly in one language, and it does not suit a build environment without a C toolchain if you want the Oniguruma regular expression mode. Verify first which selection mode your data actually needs, and note that the README's own Linux package URLs mix a v2.3.3 path with a 2.3.2 filename, so check the release page before scripting an install.

## FAQ

### How do I install teip?

With Homebrew using brew install teip, with a .deb or .rpm package on Linux, with the Windows installer for x86_64, or from source with cargo install teip. If no binary exists for your architecture, the README says to build it from source.

### How does teip select fields in a CSV file?

Use the --csv option with -f, which makes -f interpret the list as field numbers of a CSV according to RFC 4180 instead of whitespace separated fields. For TSV or other delimiters, -d takes a literal delimiter and -D takes a regular expression.

### What does the -G option do in teip?

It makes -g interpret Oniguruma regular expressions instead of the default engine. That support is an optional cargo feature, so the binary has to be built with cargo install teip --features oniguruma, and the libclang shared library must be available.

### What does the -e option in teip do?

It executes a string in another process that receives identical standard input as the main teip command, and emits numbers to be used as line numbers for actioning. The -A, -B and -C options are documented as aliases of -e with grep -n and the matching context flag.

### Does teip work on Windows?

Yes. The README gives an installer download for Windows x86_64 and points at a wiki page on using teip on Windows for the details. The crate also builds on Windows through cargo and PowerShell with chocolatey for the Oniguruma feature.

## Sources

- [greymd/teip on GitHub](https://github.com/greymd/teip)
- [Issues](https://github.com/greymd/teip/issues)
- [License: MIT](https://github.com/greymd/teip/blob/main/LICENSE)
- [README](https://github.com/greymd/teip/blob/main/README.md)
- [Releases](https://github.com/greymd/teip/releases)

---

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