On 9/13/23 11:01 AM, Oliver Kiddle wrote:
> Within limits, it's possible with rxvt-unicode.
I may be wrong, or have misunderstood what the OP is wanting to do. But
I disagree.
> The escape sequence \e[0i is equivalent to pressing Shift-Print_Screen
> which is for sending the scrollback buffer to a printer. To actually
> capture the output you need to send it to a file instead of a printer
> which is configured from .Xresources, e.g. as
>
> Rxvt.print-pipe: umask 077;cat >/tmp/XXX
XTerm supports DEC's "Media Copy" feature.
> Same basic concept may work with other terminals but the data is
> being dumped to a file rather than sent down the tty line. So given
> ssh connections or permission changes the zsh completion widget at
> the other end won't be able to read it.
My understanding is that the OP wanted the data to go back to the host
sending the control sequences, not a local file / printer. Ergo why I
say that rxvt's feature you're talking about and XTerm's Media Copy
feature won't do what I understand the OP to want to do.
My understanding is that the OP wanted the host to be able to scrape the
screen so that it could intelligently modify something on the screen,
ostensibly something like command completion or such such handy behavior.
> And I'd agree with Grant that the entire concept is questionable from
> a security perspective. Many terminals removed even the feature for
> retrieving the title bar text.
I'm okay with the idea of having the terminal switch it's output to a
local AUXiliary port -- ostensibly connected to a printer -- redirect
/future/ output to said AUX port & printer. At least until the terminal
is directed to start sending things to the screen again.
> Aside from tmux, screen also has the feature with screen -X hardcopy
Sending existing screen contents back to the host is considerably
different than sending new content to an alternate location.
--
Grant. . . .
unix || die