putty resize action

[Mark Richards]

I found a nice script (below) which resizes the terminal session to match that of the putty window.

It would be sweet if putty provided a trigger event which will launch the script in my terminal session when the window has been re-sized. Ideally, the script would be launched after a slight delay following mouse up after the re-size action.

Of course, the script can't launch if a user is not at a command prompt. Not certain how putty might make this distinction.

Which is probably why the feature has not been implemented?


from: https://raw.githubusercontent.com/akkana/scripts/master/termsize


#!/usr/bin/env python

# Get the current size of the terminal window, and set stty size accordingly.
# A replacement for xterm's resize program, with no X dependency.
# Useful when logged in over a serial line.
# Copyright 2013 by Akkana Peck -- share and enjoy under the GPL v2 or later.

import os, sys
import fcntl
import posix
import struct
import time
import re
import termios
import select

tty = open('/dev/tty', 'r+')
tty.write('\033[7\033[r\033[999;999H\033[6n')
tty.flush()

fd = sys.stdin.fileno()

oldterm = termios.tcgetattr(fd)
newattr = oldterm[:]
newattr[3] = newattr[3] & ~termios.ICANON & ~termios.ECHO
termios.tcsetattr(fd, termios.TCSANOW, newattr)

oldflags = fcntl.fcntl(fd, fcntl.F_GETFL)
fcntl.fcntl(fd, fcntl.F_SETFL, oldflags | os.O_NONBLOCK)

try:
while True:
r, w, e = select.select([fd], [], [])
if r:
output = sys.stdin.read()
break
finally:
termios.tcsetattr(fd, termios.TCSAFLUSH, oldterm)
fcntl.fcntl(fd, fcntl.F_SETFL, oldflags)

rows, cols = map(int, re.findall(r'\d+', output))

fcntl.ioctl(fd, termios.TIOCSWINSZ,
struct.pack("HHHH", rows, cols, 0, 0))

print "\nReset the terminal to", rows, "rows", cols, "cols"

[Simon Tatham]

Mark Richards <kmal...@gmail.com> wrote:
> It would be sweet if putty provided a trigger event which will launch
> the script in my terminal session when the window has been re-sized.
> Ideally, the script would be launched after a slight delay following
> mouse up after the re-size action.

Hmmm. The idea being that you use this when PuTTY is talking to a
serial line, or for some other reason the usual Telnet/SSH mechanism
for auto-notifying the server about window resizes is not available or
not working?

> Of course, the script can't launch if a user is not at a command prompt.
> Not certain how putty might make this distinction.

Yes, that would be tricky. You could imagine emitting some kind of
escape sequence which would notify PuTTY when you entered and left
command-prompt mode, but that would be pretty fragile - no end of
glitches could cause one of those sequences to be dropped by mistake,
and even _in_ command-prompt mode just sending the command followed by
Return would be iffy if you had another command half-typed.

If I wanted a serial-port connection to pick up my window resizes
automatically, I'd probably prefer to do it by putting an extra
protocol layer _between_ the raw serial line and the tty session - and
the obvious protocol to choose would be Telnet, which is conveniently
lightweight and already has built-in window-size notification.

Setting up such a session would be fiddly - you'd have to make PuTTY
believe it was speaking Telnet but have it use Plink in serial mode
(or equivalent) as a local proxy command, and on the server end you'd
have to run a telnetd with some curious options wrapping your shell
(in fact it's quite possible that using the simplistic one in
putty/contrib/cygtermd might be easier than persuading the system
telnetd to do what you wanted), and if you didn't have hardware flow
control then you'd also have to bodge all of this to cope somehow with
XON/XOFF - but once you'd got it working, window resizes would be
picked up even in the middle of running a full-screen application such
as an editor. (Which would be important to me, since editing sessions
are often the moment when I suddenly _realise_ I want to make my
window wider!)
--
import hashlib; print (lambda p,q,g,y,r,s,m: m if (lambda w:(pow(g,int(hashlib.
sha1(m).hexdigest(),16)*w%q,p)*pow(y,r*w%q,p)%p)%q)(pow(s,q-2,q))==r else "!"
)(0xb80b5dacabab6145, 0xf70027d345023, 0x7643bc4018957897, 0x11c2e5d9951130c9,
0xa54d9cbe4e8ab, 0x746c50eaa1910, "Simon Tatham <ana...@pobox.com>")

[Kaz Kylheku]

On 2014-08-13, Mark Richards <kmal...@gmail.com> wrote:
> I found a nice script (below) which resizes the terminal session to match
> that of the putty window.

This is already found in almost any Linux distro in the form of a
program called "resize". Resize interrogates the terminal, sets up
the kernel tty parameters, and also outputs the shell variables LINES
and COLUMNS in a syntax that you can eval:

$ eval $(resize) # done!

The program comes from the X11 package, and so it may be missing from
some embedded Linux distros. For that reason, I wrote a shell script
clone.

http://www.kylheku.com/cgit/unix-cruft/tree/resize

This is used int the same way: using eval $(resize).

It has no dependencies on termcap; it only works with VT100 compatible
terminals. Also, unlike the X11 version, it has no command line option
for emitting variables in C shell syntax.

> It would be sweet if putty provided a trigger event which will launch the
> script in my terminal session when the window has been re-sized.

It does; the SIGWINCH signal is generated. Notification of resize which cuses
the tty driver to generate a SIGWINCH works over ssh, and I think telnet and
rsh also.

These programs are for the remaining situations in which that doesn't
happen, like when you're using a terminal emulator over serial line,
where there is no protocol for communicating resize.

(And that brings us to small Linux embedded systems again: you have no resize
program in the distro, and your console is a serial line.)

If SIGWINCH is being generated, you do not need this utility. Most users of
modern Linux have not heard of this, because resizing works for all the GUI
terminals on their desktops, as well as for SSH sessions.

> Ideally, the script would be launched after a slight delay following mouse up
> after the re-size action.

So, forget it.

> print "\nReset the terminal to", rows, "rows", cols, "cols"

This script forgot to emit the shell variables to be evaled.

To work around this, after you run the script, do a "kill -WINCH $$"
which will cause the shell to believe it was delivered a window change
signal, and respond by pulling the values from from the tty, stuffing them into
the LINES and COLUMNS variables.

You're better off using the de-facto standard eval $(resize).

[Kaz Kylheku]

On 2014-08-13, Mark Richards <kmal...@gmail.com> wrote:

> # Get the current size of the terminal window, and set stty size accordingly.
> # A replacement for xterm's resize program, with no X dependency.

No X dependency, but a Python dependency for something which can be done with
the shell, the "stty" util and "dd".

[xjaso...@gmail.com]

So, Im probably not in the right place but im getting kind of desperate here.
When I resize my putty window by simply dragging the window border, it closes whatever ssh session I am currently in. Some details: I am using the latest version from the website. Lets say I do a ./start Network/tunnelConnect.py -p 22 into a remote linux machine. Ok great...I am on that machine and it tells me 'root@machinename' at the prompt. Now I am running commands, tailing logs, etc and I find that I need to make the window bigger. I resize the window and it closes my session immediately with "Cleaning up...Done!", and then I am back at my local user prompt 'user@locallinuxbox'. The resizing option is set to "change number of rows and columns when resized" so I changed it to "change font when resized". This works, in that it doesnt end my session when the window is resized, but I do not like this option as I want to see more text when I resize, not just make the font bigger. Why is it ending my session when its resized? I wonder if its just not passing the new size to the application correctly? In which case, I would expect a blank page instead of just being signed out. I am at a loss and would love some help (been putting up with this for like 5 years). Thanks!!

Jason Egan
xjaso...@gmail.com

[Kaz Kylheku]

On 2019-03-26, xjaso...@gmail.com <xjaso...@gmail.com> wrote:
> So, Im probably not in the right place but im getting kind of desperate here.
> When I resize my putty window by simply dragging the window border,
> it closes whatever ssh session I am currently in. Some details: I
> am using the latest version from the website. Lets say I do a
> ./start Network/tunnelConnect.py -p 22 into a remote linux machine.

Does it reproduce if you just use "ssh" to connect to the remote machine
like a normal person, instead relying on the above Python wrapper?

It smells like something might be getting a SIGWINCH signal from the
terminal resize and is not prepared to handle it.

Normally programs don't have know about the existence of SIGWINCH
because its default action is for it to be ignored. That's why in
everyday experience, programs don't terminate when the terminal
window is resized, even though they don't make any arrangements
regarding SIGWINCH.

--
TXR Programming Lanuage: http://nongnu.org/txr
Music DIY Mailing List: http://www.kylheku.com/diy
ADA MP-1 Mailing List: http://www.kylheku.com/mp1

[xjaso...@gmail.com]

I wouldnt know how to just use ssh in our environment once im puttied into my linux box. ...our hostnames arent recognized unless you use the python command. I am on a windows box using putty to ssh into my linux box behind me...and from there I connect to the customers machine.

[xjaso...@gmail.com]

Im gonna cat the tunnelconnect.py file and see what its doing real quick

[xjaso...@gmail.com]

That tunnelconnect wrapper is like 500 lines of code...so yeah i am not sure how to get around connecting to a machine without using it.

[Kaz Kylheku]

Problem is, there is no reason to believe that the problem is anywhere
else but that Pythonology that you have there; so you either have to
debug into that yourself, or report this crippling issue to its
maintainers/purveyors.

Read the code to find out what it's doing; it must be getting host names
or IP addresses from somewhere. Try connecting to those same host names
directly using "ssh". If the resize problem is not reproducible that
way, the problem is in the connect script.

[Kaz Kylheku]

On 2019-03-26, xjaso...@gmail.com <xjaso...@gmail.com> wrote:
> That tunnelconnect wrapper is like 500 lines of code...so yeah i am
> not sure how to get around connecting to a machine without using it.

Add some print statements to it. At some point it has to call ssh
with some arguments, right? So print that command line or those
arguments.

You could also run that command under strace -f.

[Kaz Kylheku]

On 2019-03-26, Kaz Kylheku <157-07...@kylheku.com> wrote:
> Problem is, there is no reason to believe that the problem is anywhere
> else but that Pythonology that you have there; so you either have to
> debug into that yourself, or report this crippling issue to its
> maintainers/purveyors.

Also: you've been tolerating this problem for five years, right?
How many times have you upgraded tunnelConnect.py script in that
time? Maybe there are newer versions of it?

[Grant Taylor]

On 3/26/19 3:09 PM, xjaso...@gmail.com wrote:
> That tunnelconnect wrapper is like 500 lines of code...so yeah i am not
> sure how to get around connecting to a machine without using it.

Without knowing what tunnelConnect.py is doing, there's little that we
can do to help.

Do you want to provide a copy of it? Here or email?

There's always a chance that it's doing something extremely complex.
But I'm getting it can be replaced with a judiciously crafted
~/.ssh/config file.



--
Grant. . . .
unix || die

[xjaso...@gmail.com]

Sorry for the late reply. I am just4 the technical support person for the product and only know linux inside the scope of my job. I am not a developer, nor did I develop the 10 year old python code that makes up our system. I was assuming the issue was PUTTY related, which is why I didnt contact the developers and instead came here. Once you helped me realize it was a python code issue, I contacted them and they fixed it. Come to realize, my entire technical support team was also putting up with session termination on resize for the last 5 years as well...and nobody said anything!! Anyway, its fixed and will be incorporated into the next software release. Thanks for everyones insight!

[Kaz Kylheku]

On 2019-03-28, xjaso...@gmail.com <xjaso...@gmail.com> wrote:
> why I didnt contact the developers and instead came here. Once you
> helped me realize it was a python code issue, I contacted them and
> they fixed it.

Good job.

BTW that script you quoted from Mark Richards is a reimplementation of
the "resize" program from the X11 window system (which is written in C).

Except, this Python imitation doesn't output shell variables that can be
eval-ed; it just punches the terminal size down into the kernel.

Here is a shell implementation of resize:

http://www.kylheku.com/cgit/unix-cruft/tree/resize

what's missing from this one is C shell support; it spits out the LINES
and COLUMNS variable assignments in Bourne/POSIX shell syntax only.

The only situation in which we need such a thing is when working over
serial lines (with embedded hosts nowadays). When using a host over
a serial console, there is no protocol there for communicating a window
resize. A manual action has to be taken on the host to inform the kernel
of the altered window size. I wrote resize some 13 years ago for
embedded use: I didn't want to add the X11 package to the embedded
distro just to get resize. :)

If we're using ssh, resizing should work: resizing the local window
should communicate to the remote host. The struct termios structure in
the kernel on the remote end should pick up the new size, and the kernel
should send the SIGWINCH signal to the foreground process group.

[Matthew Thyer]

On Thursday, 28 March 2019 at 4:32:47 pm UTC+10:30, Kaz Kylheku wrote:
> Here is a shell implementation of resize:
>
> http://www.kylheku.com/cgit/unix-cruft/tree/resize

Unfortunately, the domain for kylheku.com has expired and the Internet Archive has never archived the domain. Maybe someone can host this elsewhere?

[Spiros Bousbouras]

Link works for me.