We are using a text based program through SSH. The session is started with a login script, which does a bit of setup then starts the program without a shell. It works well in putty. We are trying to use it with a mobile SSH client, like termius.

The problem is that the xHarbour program recognizes terminal changes like rotating the screen or closing the keyboard. So if the terminal is resized the xHarbour program knows about it and changes the console size.

With stty x rows y columns I can set the initial terminal size.

I tried putting these commands in the init script before the program starts, but if the screen size changes on the client side (closing the keyboard, rotating screen) it changes the values automatically again and messes up the output. I also used shopt -u checkwinsize, which affects the shell, making it seem as if the terminal has a fixed size, but has no effect on the xHarbour program.

Is there a way to block the SSH session from receiving the in-band commands described here? As far as I can tell I can't set the terminal size in termius. Is there an android(maybe iOS too) client that allows that?

The target system is Centos 6,7

  • Does tput work for you? For example by using "tput cup x y" you can move the cursor to the location x,y . It might cause re-rendering of the terminal screen in your remote shell. Not sure . Try it. May 29 '20 at 20:19
  • I corrected some of the errors, but I couldn't make head nor tail of what It remains fixed with these commands in a shell, but not in the program. is supposed to mean.
    – JdeBP
    May 29 '20 at 20:22
  • I can't run shell commands once the program is started. At least not from the program, it's really agnostic about it's environment it even runs in a windows console. May 29 '20 at 20:22
  • Thank you for trying to help, but the problem is exactly the opposite, the program changes the terminal size, it should stay fixed. And in the link that you wrote it says: Auto detect terminal size in *nixes when application runs in TTY device. I don't want it to know about the change. But thanks for looking it up, now I know it's baked in. I still need to know if I can block the in-band commands. May 29 '20 at 20:58
  • 1
    If the xHarbour program were changing in response to terminal size changes, there wouldn't be a problem. That description of the problem simply makes no sense. You wouldn't be seeing "messed up output", because terminal resize changes would be being sensed and accounted for by xHarbour. Not knowing about terminal size changes is the way to get messed-up output, as several Q&As here attest. For example: unix.stackexchange.com/q/577038/5132 You are I think posing your problem as exactly the opposite of what it actually is.
    – JdeBP
    May 29 '20 at 21:14

On Linux and BSD systems, when a terminal changes sizes, the process or processes attached to that terminal receive a SIGWINCH. The default behavior is to ignore this signal, but processes that do screen drawing, including programs using ncurses, catch this signal and adjust the display accordingly.

The messages that get sent over SSH cause the size of the terminal to be adjusted and therefore your process to receive SIGWINCH. OpenSSH doesn't provide a way to control these because this is part of having a fully functional terminal emulation and allowing people to pick and choose which parts of their terminal they would like to function would lead to an impossibly difficult environment for programs. However, if you don't want your process to have a terminal, you can invoke it over SSH with the -T option, and then it will not. It will also have no capability to redraw the screen, because it will have no terminal or terminal type set. This may be the behavior you're looking for, though.

If you really do want to never redraw the screen, you could try spawning your process from a wrapper program that ignores SIGWINCH. It looks like some versions of ncurses do honor that. You could also wrap your process with one that gives it its own pty and just forwards that to the original terminal. That would be pretty complex, though.

However, overall, this doesn't seem like a behavior you'd typically want. Programs are supposed to be responsive to the terminal, and this is generally standard Unix behavior that's considered to be desirable. If you do get this to work, you're probably going to end up with a lot of broken rendering and be generally unhappy with the result.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.