8 comments

[ 0.27 ms ] story [ 33.3 ms ] thread
Why vi-pipe instead of a combination of tee, <insert editor of choice>, and named pipe?
this is easier and relays changes by storing a diff
ok, sidestepping using non-vi editor instead of vi. Why not vim & relevant macro instead of vi-pipe to do same function?
you can use any editor you like. could be vi, vim, nvim, emacs. the point is that your editor receives text from stdin, and writes changes to stdout, in the middle of a pipeline.

hopefully the examples in the readme make sense but maybe not?

Not clear what advantage vi-pipe offers over already available ways to make use of an editor in the middle of a command line pipeline. aka built-in shell functionality, available program(s) and/or OS provided features (aka named pipe and/or redirection to/from editor from a socket).

beginning of pipeline > output.txt; <editor of choice> output.txt; cat output.txt | rest of pipeline commands

sed, stream editor, takes text from standard in and writes changes to standard out in the middle of a pipeline. sed does this without all the extra overhead a standard editor incurs.

More flexibility with awk, but also more overhead than sed, but less than vim.

With a bit of macro magic and/or readning from/writing out to named pipe, can do the same interactively with vim.

Useful for command line testing of different malloc implimentations, real time system responsiveness via pv, and/or help tuning system internet buffers (aka tcp/ip). An automatically resizable buffer for vi-pipe would be helpful for command line malloc implimentations test via dd & pv commands.
This is pretty nifty and I could see it being quite handy for building one-off pipelines. The whole storing a diff of your change and reapplying it in the pipeline is super clever, though I'd have concerns about how the diff algo would handle different types of source input.

It was only after squinting for a bit and mentally parsing the example code that I had the a-ha moment and understood when/why I'd want to use this though. Maybe a video or asciicinema/terminalizer recording showing how it works in practice might help illustrate

ah you're right, I never considered non text input. I may add some special handling for that. asciienema is a good shout too