4 ms·

I'm not sure I understand; if you don't care about the output then send it to /dev/null. If you do care then pipe it to an editor. A terminal is not a text edit

I'm not sure I understand; if you don't care about the output then send it to /dev/null. If you do care then pipe it to an editor. A terminal is not a text editor (I mean, I suppose it could be, but that seems like a rather large scope change.)

terminal-survey 9y ago
I think the problem is that you only know if you care about the output after the fact. For example, if "make" runs through, I usually don't care about the output. But if "make" fails, then I want to read the error messages. As I said somewhere else, we have a concrete solution in mind for implementing folding as GP describes.
- deleted 9y ago
  [deleted]
- EpicEng 9y ago
  I don't know that make is a good example here. This is a tool you use constantly, so I imagine you'd know to pipe std err if you wanted its output. We seem to be talking about turning the terminal into a full blown editor (when we already have editors...) to satisfy a rather limited use case of 'oops, guess I have to run that again." But hey; your time to spend :)
  - khedoros1 9y ago
    > We seem to be talking about turning the terminal into a full blown editor (when we already have editors...) to satisfy a rather limited use case of 'oops, guess I have to run that again." That seems like an incredibly common use case to me. It's common for a command to have a lot more output than I originally expected, and when it happens, I usually want to examine that output in detail. It would be great to retroactively be able to open captured output in a text editor, dump it to a file, pipe it to another tool, or collapse it. I don't really want to edit the output in the terminal, but it would be great to be able to say "oops, do X with stdout from that last command, and do Y with stderr".
    - afarrell 9y ago
      FWIW, I also find myself wanting this.
UncleMeat 9y ago
Sometimes you forget. Or sometimes a command generates an unexpectedly large amount of output. This is a tool that I use every day. Usability should be a priority. Even if there is a more complex way of doing something, it is better if there is a simple way.

terminal-survey 9y ago

I think the problem is that you only know if you care about the output after the fact. For example, if "make" runs through, I usually don't care about the output. But if "make" fails, then I want to read the error messages. As I said somewhere else, we have a concrete solution in mind for implementing folding as GP describes.

deleted 9y ago
[deleted]
EpicEng 9y ago
I don't know that make is a good example here. This is a tool you use constantly, so I imagine you'd know to pipe std err if you wanted its output. We seem to be talking about turning the terminal into a full blown editor (when we already have editors...) to satisfy a rather limited use case of 'oops, guess I have to run that again." But hey; your time to spend :)
- khedoros1 9y ago
  > We seem to be talking about turning the terminal into a full blown editor (when we already have editors...) to satisfy a rather limited use case of 'oops, guess I have to run that again." That seems like an incredibly common use case to me. It's common for a command to have a lot more output than I originally expected, and when it happens, I usually want to examine that output in detail. It would be great to retroactively be able to open captured output in a text editor, dump it to a file, pipe it to another tool, or collapse it. I don't really want to edit the output in the terminal, but it would be great to be able to say "oops, do X with stdout from that last command, and do Y with stderr".
  - afarrell 9y ago
    FWIW, I also find myself wanting this.

UncleMeat 9y ago

Sometimes you forget. Or sometimes a command generates an unexpectedly large amount of output. This is a tool that I use every day. Usability should be a priority. Even if there is a more complex way of doing something, it is better if there is a simple way.