Automatic stdout/err redirection

Automatic stdout/err redirection

[Yuri D'Elia]

I've been thinking for a while about the ability to manipulate the
output of the previous command without executing it again. It's such a
common occurrence...

Imagine the following desired behavior:

- when executed interactively, each cmdline redirects the stdout to some
  temporary $FILE in _addition_ to stdout
- we want to fool the pipeline into thinking that stdout is still a TTY
  and disable buffering (I don't want any change in regular command
  behavior)
- stdout though is not directly flushed to the pty, it's actually
  filtered by something inbetween like "head -25" that shows the first
  25 lines only, and then shows a message "truncated output" when this
  occurs, without flooding the terminal
- the full output is still available in $FILE

Working with such a setup would be generally much more convenient.

The output of each command is temporarily saved, so that it can be
re-used again into filters without executing the command again. Or
simply less'ed (no more ugly scrollback buffer search needed!).

No more terminal flooding in case of silly mistakes.

I started thinking into how to use the preexec hook to achieve something
like that, but it's definitely non-trivial. Most of the required pieces
would be available, for example combining zpty with multiios, but the
devil is in the details.

The main issue would be using interactive programs, or programs that
rely on escape sequences, such as [n]curses.

Using "head" as a filter is not enough, one would need to implement
something a bit more sophisticated, that detects the presence of escapes
and disables any input processing.

Icing on the cake would be to duplicate stdin itself (when it's coming
from the tty) and attach a copy to the "head" filter itself, so that we
could trap extra escape sequences and introduce some interactive
behavior in the filter. An example would be a command to say "show me
the output anyway" after the truncation limit has been hit.

Just as a general opinion, what would you think about the behavior?

Re: Automatic stdout/err redirection

[Bart Schaefer]

On Nov 11,  4:12pm, Yuri D'Elia wrote:
}
} I've been thinking for a while about the ability to manipulate the
} output of the previous command without executing it again. It's such a
} common occurrence...
} 
} Just as a general opinion, what would you think about the behavior?

This has come up before and for practical purposes it just doesn't work
to try to build this into the shell, not least because of the trouble
you called out with interactive or "fullscreen" commands like editors.

It's also what the script(1) command is expressly designed for.

There are a couple of possible approaches:

1. Run your entire zsh session inside "script", capturing everything to
the same file.  Use preexec and precmd to output boundary markers so
that the typescript file can be sliced up later into the output of
individiual commands vs. the output of the shell between commands, and
have widgets or other functions to selectively grab the previous output.

2. Use preexec or an accept-line wrapper or zle-line-finish hook to run
each command inside "script -c '...'".  This gets tricky as you have to
differentiate external commands from shell builtins in order to avoid
breaking the semantics of assignments etc., and loops or if/else are a
difficult problem to address.

You could also write your own "script"-alike using zpty, but that would
end up looking very much like option #1 above, I think.  With #1 you
could even have the typescript file accessible through the zsh/mapfile
module for access to the sections.

Re: Automatic stdout/err redirection

[Sebastian Gniazdowski]

On 11 Nov 2017 at 16:12:54, Yuri D'Elia (wavexx@thregr.org) wrote:
> I've been thinking for a while about the ability to manipulate the
> output of the previous command without executing it again. It's such a
> common occurrence...
>  
> Imagine the following desired behavior:
>  
> - when executed interactively, each cmdline redirects the stdout to some
> temporary $FILE in _addition_ to stdout
> - we want to fool the pipeline into thinking that stdout is still a TTY
> and disable buffering (I don't want any change in regular command
> behavior)
> - stdout though is not directly flushed to the pty, it's actually
> filtered by something inbetween like "head -25" that shows the first
> 25 lines only, and then shows a message "truncated output" when this
> occurs, without flooding the terminal
> - the full output is still available in $FILE

I've tried to approach this. I think it would require additional process to accumulate the screen data, at least when adding to current Zsh. It is somewhat doable, even with fullscreen programs, because it can currently be done with Tmux:

https://blog.plenz.com/2012-01/zsh-complete-words-from-tmux-pane.html

So at least the most straightforward use cause – complete words from screen – is doable. This hints that what would have to be built into Zsh is a terminal multiplexer.

Nevertheless I've also tried with Zsh script code:

https://github.com/psprint/ztrace

This isn't a successful plugin because of the fullscreen issues, but it explores the topic, I think.

--  
Sebastian Gniazdowski
psprint /at/ zdharma.org