0

I'm looking for a way to get resize events on an xterm as an alternative to the winch signal. I need to get a signal for the xterm resize that is remote compatible, that is, could be used over a serial line/telnet/ssh/whatever. The winch signal is only for local machine tasks.

I know that vi/curses can do this because I have tried ssh and use vi to edit a file, and it responds to resizing of the window.

Carlos Cavero
  • 3,011
  • 5
  • 21
  • 41
Scott Franco
  • 11
  • If you're using telnet or something that uses the same protocol, there's [RFC 1073](https://tools.ietf.org/html/rfc1073). – Shawn May 06 '19 at 18:42
  • For ssh, it's in [RFC 4254](https://www.ietf.org/rfc/rfc4254.txt). I assume the window dimension change message triggers a SIGWINCH on the remote end. – Shawn May 06 '19 at 18:47
  • out of band, eh? I assume that would not work on a (say) serial connection. It does explain why vi/curses can do it. I was sorta hoping for something like the mouse tracker protocol where the xterm sends you escapes down the line... but I can live with this solution. – Scott Franco May 06 '19 at 18:58
  • Generically, it's from [RFC 1073](https://tools.ietf.org/html/rfc1073); ssh inherits that. Pointing out that a ***serial*** line doesn't support the feature makes this a duplicate. – Thomas Dickey May 07 '19 at 08:11
  • Possible duplicate of [How to detect screen resize events coming from ncurses in QNX?](https://stackoverflow.com/questions/54665257/how-to-detect-screen-resize-events-coming-from-ncurses-in-qnx) – Thomas Dickey May 07 '19 at 08:13
  • Could be a dup, but the question is not QNX specific. – Scott Franco May 07 '19 at 14:08

1 Answers1

-1

So after a bit of research, it does seem there is no in-band method for this. I don't think it would be difficult to add. You have two sides to a connection, ssh, serial or whatever, let's say A and B where A is on the host and B is the remote. To get behavior equivalent to a local windowed task, I would say at least two things are essential:

  1. Mouse movement/button messaging.
  2. Window resize messaging.

The second, can be a two step process. If the B task gets an alert that the window size has changed, it can use in band queries to determine what the new size is, using the (perhaps infamous) method of setting the cursor to the end of an impossibly large screen and then reading the actual location of the cursor that results, then restoring the location, all done with standard in-band controls.

Why care about in-band vs. out of band? Well, nobody cares now :-), but serial lines used to be quite popular, and in-band, that is, actual escape sequences sent down the line are going to work, but telnet or ssh "out of band" communication is not.

It would not be difficult to add, a local program that shims the ssh or telnet, or even xterm itself, can get the winch message and change that to an escape alert to the B side. Here the mouse messaging is instructive. The messages consist of two actions:

  1. The B side must enable such messages, so that the A side won't send unknown escapes to it.
  2. The A side must have an escape to signify winch.

Thus a new escape from B to A, and one from A to B.

I'm actually fairly satisfied with winch. What was wanted is to have the same capabilities as vi/curses (based on my observation). This kind of support is already far better than Windows, which (as far as I know) implements none of this remote side support.

Scott Franco
  • 481
  • 2
  • 15