A developer set out to build a better shell. He ended up building something that sits underneath the shell instead - and it's more useful.
The project is called ptylenz, and it's a PTY proxy that structures terminal output into navigable blocks with search and copy functionality. The insight that made it work: the shell isn't on the data path where output matters. The PTY is. That forced a complete rethink of where to intervene.
The Problem with Terminal Output
Terminal output is a stream of text. Commands produce output, it scrolls past, and if you want to find something you either scroll back through history or pipe to grep. There's no structure. No way to say "show me just the output from that git status command three commands ago".
Most attempts to fix this focus on the shell itself. Build a better shell, add features for output parsing, create custom integrations. But that means rewriting bash or zsh or fish, convincing people to switch, and maintaining compatibility with decades of existing tooling.
The developer behind ptylenz tried that approach. It didn't work. The shell is too complex, too deeply integrated into workflows, too hard to replace. So he went looking for a different intervention point.
What a PTY Actually Does
A PTY (pseudo-terminal) sits between the shell and the terminal emulator. It's the layer that handles the raw input and output. When you type a command, it goes through the PTY. When a command produces output, it comes back through the PTY. Every byte of data passes through this layer.
That makes it the perfect place to inject structure. You don't need to modify the shell. You don't need to change how commands work. You just intercept the data as it flows through the PTY, parse it, and structure it before it reaches the terminal.
Ptylenz does exactly that. It's a proxy that sits on the PTY layer, captures command output, breaks it into blocks, and makes each block individually searchable and copyable. The shell never knows it's there. The commands run normally. But the output is suddenly navigable in ways it wasn't before.
Why This Approach Works
Building at the PTY layer means compatibility. It works with any shell - bash, zsh, fish, whatever. It works with any command. It doesn't require changing your workflow or learning new syntax. You just run your commands as normal, and the output is structured automatically.
The key features: output is broken into blocks per command, each block can be searched independently, you can copy a block without scrolling, and there's a navigation interface to jump between commands. It's not significant - it's just solving the basic problem that terminal output is hard to work with.
The developer describes the realisation moment: he was trying to build features into a shell and kept hitting walls. Then he looked at the data path and realised the shell wasn't on it for output. The PTY was. That shift in perspective - from "where does the feature belong?" to "where is the data actually flowing?" - unlocked the solution.
What This Teaches About Architecture
The lesson here isn't about terminals specifically. It's about finding the right layer to solve a problem. The obvious place is often wrong. The shell feels like the natural place to add shell features. But the PTY is where the data lives, so that's where the solution needs to be.
This happens constantly in software. You want to add logging, so you modify the application. But the right place might be the web server. You want to add caching, so you change the database queries. But the right place might be a proxy layer. The question isn't "where does this feature logically belong?" - it's "where is the use point in the data flow?"
Ptylenz found its use point by working backwards from the constraint. Modifying the shell was too hard. Modifying terminal emulators was too fragmented. The PTY was the choke point where all data passed through, so that's where the intervention happened.
Building Something You Actually Use
The other detail worth noting: the developer built this because he wanted it. Not as a side project to learn Rust, not to get GitHub stars, but because terminal output was genuinely annoying and he wanted a better way to navigate it.
That's why it works. It solves a real problem he encounters daily. The features aren't hypothetical - they're the things he actually needs when working in a terminal. Search across command output. Copy a specific block without scrolling. Jump back to see what a command printed five steps ago.
The best tools come from builders scratching their own itch. They don't have to guess what users need - they are the user. Ptylenz is a good example of that. It's not trying to reimagine the terminal. It's just making the existing terminal less frustrating to use.
Read the full writeup and grab the code at DEV.to.