[idea] show output from last successful command

[Michael Mior]

While typing a command, when I'm in the middle, of course it's going to fail while I'm still writing it because it's not complete. In addition to showing the error from the command in progress, it would be great to also show the result of the previous command so I can remember what the output looks like. Cool tool though :)

[Mateusz Czapliński]

Wow, interesting idea, haven't occurred to me before! Thanks a lot! I'll totally try to think about it more, how I'd best like to see something like this work... there's so many options...

[Michael Mior]

No problem. Actually on further thought, even if the command succeeds, it would still be helpful to see the output from the previous command in the pipeline since I might not have entered the correct command yet and it might be hard to do so without seeing the input I'm actually working with.

[Mateusz Czapliński]

As a side effect of adding the "Press Enter to run" feature in v0.2+, in my experience at least, I think the original issue is now somewhat mitigated (the "earlier output" doesn't disappear so fast now) — at least less glaring.

---

As to what more can be done, as of now I have two general ideas for directions in which this idea could be taken:

• a) A new shortcut key would "split" a pipeline, by inserting a "super-powered" | character. The "segments" before and after this super-| would be processed by separate instances of $SHELL subprocess. Jumping left/right of the super-| would show the old/new output.

  • (+) this would nicely open a way for future forking & merging of pipelines;
  • (+) this would make it easier to speed up processing of "later" segments of the pipeline, as they could read from the earlier buffers;
  • [LATER] a decision would have to be made how to handle "regular" | signs entered by user (the can occur alone, but also as parts of strings, be escaped by \, etc.; writing a parser for this doesn't seem reasonable, as we are open to various shells/engines via $SHELL; unless we embed Lua, but this then would become error-prone)
  • [LATER] a decision would have to be made how to build upN.sh shells to preserve the semantics of handling super-| vs. normal | vs. \|, etc.

• b) A keyboard shortcut could exist which would create a (numbered?) "snapshot" of a pair (command, output). There could then be some way to browse and recall (restore, load) such snapshots.

  • (+) this would be more useful for non-shell scripts (like python, ghci) than (a) — because (a) wouldn't allow passing of variables between "segments";
  • (+) this could be helpful as a kind of an "undo" feature.

• c) The original idea of just showing output of last command that exited with status 0 could still be useful and valuable anyway.

[Michael Mior]

I think this does mostly solve the problem so I'd say I'm fine with this being closed if you wish.

[Yuri Bochkarev]

An idea similar to "superpowered" | was discussed in a Radio T podcast (https://radio-t.com/p/2018/10/27/podcast-621/), where this tool was discussed. It was compared with Java Streams and it was said that even though streams is a powerful and expressive device, what it lacks is seeing the intermediate steps (but that is actually supported by IntelliJ Idea).

So I was thinking about this mode when the whole command gets parsed and you don't just see the resulting output of the whole long command, but you see the output of the current and the previous command block that you're editing now, e.g. in a command:

input | cmd1 foo bar | cmd2 bax qux | awk
                            ^- the cursor is here

you should see the output of cmd2 and the output of cmd1 (the previous command) to help you understand the data transformation better.

[Mateusz Czapliński]

@balta2ar:

Oh, lol, it's weird and funny getting somewhat popular and suddenly seeing my tool featured at various curious places :)

But, back to the matter at hand: I'm not planning to write a parser, sorry. Even if I focused purely on bash, it would be super hard; but up already allows plugging in any interpreter anyone might want through $SHELL, and writing a parser for all existing languages in the world, as well as ones not yet created, is, umm, like... not humanly possible. Whereas, I'm just a human.

Please however see pipecut for an earlier project attempting something like that. (I learnt about it only after I already wrote up. Both projects share the main idea, however the execution differs in some ways.)

One theoretical alternative might be to embed e.g. Lua in up, and allow users to provide their own parsers for any interpreter they want. But I currently don't plan to follow this path, either. If you want to try, you're welcome to fork, add this feature, and hopefully tell us about your experiences (or you may just run away with it, I'm in no power to hold you back).

edit: And by the way, for more complex data flow/stream constructions, I especially recommend checking out Luna language. I believe it's a revolutionary project, and I hope up will become obsoleted by Luna at some point in the future.