The pipecut roadmap

If you've tried it by now, you can see that pipecut has many uses. It also unlocks many ways of using Unix commands that couldn't be done with purely literal interpretations of them.

Version 1.0 - Updated December 3rd, 2014

What's on the Roadmap?

It's a long list. There are several stages to the plans I have for pipecut. Most are just a simple matter of having time to write the code - but it is my intention to stage the releases in a way that makes pipecut more functional over time, cleaning up the central UI and library first, and adding the more esoteric features gradually.

Longer term features

Some of the things that pipecut can enable are large projects of their own. They wouldn't be possible without the framework that pipecut provides, but they require significant additional effort beyond what has already been done for pipecut.

Code generation framework

In order to support generation of code in a variety of languages, pipecut needs a framework for consuming language templates that provide code segments that provide a native (to the target language) implementation equivalent to 'shell' utilities.

Social functions

Utility features for importing, exporting, and sending toolsets to other pipecut users.

Configurable keymapping

The pipecut POC has hardcoded hotkeys. These will all be user-configurable later.

Additional background data analysis

Most modern computers being used interactively have CPU, RAM, and I/O bandwidth to spare. The POC version of pipecut spawned a background thread that did some basic analysis on the input. I'll probably leave this out of the first release, then further enhance it before the feature returns. Knowing characteristics of the data file (a signature) can be useful in a tool like pipecut, for prompting users about likely mistakes, or predicting their intentions.

AST optimizations and alternate representations

Many AST nodes have multiple representations: Folding multiple egreps into a single egrep expression, grep implemented as sed or awk commands, etc. It may be useful to allow cycling through the representations for one or more blades.

Framework for command line options

Pipecut's UI can be made stronger if it has a complete understanding of all the command line utilities, their options and optional arguments. i.e. Pipecut needs to understand the 'usage' of every command it wants to provide additional functionality around. This could be done through manual configuration files, but there are some other approaches that may be possible instead.

Code generation API One

The first level code generation API will use the generation framework described above. It will walk the linear pipeline, and generate a simple concatenated piece of code in the target language. It may use blackboxes (pipe(2) calls) in the target language, but will prefer native implementations (or calls to library functions) where possible. It may use any optimization level of the AST, and may use backtracking to identify the optimization level that minimizes use of blackboxes in the target language.

Code generation API Two

The second level code generation API will consist of a set of functions and macros to 'walk' and 'query' the AST, and will allow a determined programmer to write a more refined code generator which can include optimizations appropriate for the target lanaguge which an language-specific transformer can provide.

Recent Feature Request(s):


• Emacs key bindings.
• Recording of pipecut sessions, export as iPython 'Notebook' format.
• Hotkey to activate RE highlighting during entry of Blackbox commands.
• Optimizations (internal version) for 'cut' utility.