Re: Is there a way of getting current xterm buffer?

[Sebastian Gniazdowski <sgniazdowski@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2440 bytes --]

It fine to save the screen copy to a file, I can read it via $(<file). Does
xterm can save the screen to a file, via the "media-copy" control seq that
you've mentioned? Is there some example available of how to use it?

On Wed, 13 Sept 2023 at 14:01, Grant Taylor <gtaylor@tnetconsulting.net>
wrote:

> 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
>
>

-- 
Best regards,
Sebastian Gniazdowski

[-- Attachment #2: Type: text/html, Size: 3214 bytes --]