3 ms·

Show HN: Vi-pipe, edit and replay text changes in the middle of a shell pipeline

sargstuff 4y ago
Why vi-pipe instead of a combination of tee, <insert editor of choice>, and named pipe?
- commotionfever 4y ago
  this is easier and relays changes by storing a diff
  - sargstuff 4y ago
    ok, sidestepping using non-vi editor instead of vi. Why not vim & relevant macro instead of vi-pipe to do same function?
    - commotionfever 4y ago
      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?
      - sargstuff 4y ago
        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.
        sargstuff 4y ago
        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.
nikvdp 4y ago
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
- commotionfever 4y ago
  ah you're right, I never considered non text input. I may add some special handling for that. asciienema is a good shout too

Why vi-pipe instead of a combination of tee, <insert editor of choice>, and named pipe?

commotionfever 4y ago
this is easier and relays changes by storing a diff
- sargstuff 4y ago
  ok, sidestepping using non-vi editor instead of vi. Why not vim & relevant macro instead of vi-pipe to do same function?
  - commotionfever 4y ago
    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?
    - sargstuff 4y ago
      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.
      - sargstuff 4y ago
        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

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