[TOGoS]

Thanks. The case about background processes makes it click. I would expect communication between the terminal app and the shell on the other end to still use in-band signalling, since it might be over RS-232 or SSH or anything else, but then that process that's currently playing mainframe would want to propagate that information to everything 'behind' it, and a signal makes sense for that.

[gomijacogeo]

If you dig into the RFCs, you'll see that ssh and telnet can negotiate whether each end can send/receive out-of-band messages about changes to window size. If they both can, the client side gets a local SIGWINCH, turns that into a notification over the wire, then the server side generates a SIGWINCH on its side that propagates through its pty and onto the programs attached to it.

For an rs-232 attached classic terminal that can change rows/columns, all you've really got is running eval `resize` and updating the environment variables. Most visual programs will check the environment variables on suspend/resume and maybe (it's been a while) on full-repaint (e.g. ^L on vim).

[gomijacogeo]

Upon further thought, the child can't inspect a parent's environment variables after forking, so my thinking of ^Z eval `resize`; fg can't be the way it worked. Maybe quit and restart vi was the only way back then. It's a been a while.

[gomijacogeo]

e.g. https://datatracker.ietf.org/doc/html/rfc1073