-1

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

Csaba Mihaly
  • 61
  • 5
  • Does [tput](https://linux.die.net/man/1/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. – Parsa Mousavi 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. – Csaba Mihaly 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. – Csaba Mihaly May 29 '20 at 20:58
  • If your client app (an xHarbour program) doesn't understand winsize change events, then what's the point in trying to filter these out from ssh? It wouldn't change anything. Your app would still operate according to its no-longer-correct belief about the window size, and whenever it paints something, the entire display could easily fall apart. – egmont May 29 '20 at 21:14
  • 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: https://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
  • 1. It understands winsize changes. Tried using mc with disabled checkwinsize, it remains how it was, because the console is the same size. Since the xharbour program understands the changes it tries to redraw and it gets messed up... I'm just asking if there is the way to block these in-band commands. – Csaba Mihaly May 29 '20 at 21:20
  • (You changed the title of the post from "does not understand" to "understands". This is how JdeBP and me could post an answer at the same time, to two opposite questions.) – egmont May 29 '20 at 21:20
  • checkwinsize is bash's internal thing, cannot affect mc. "I'm just asking if there is the way to block these in-band commands." - not that I'm aware of, but the context for this request really doesn't make sense to me (and apparently to others either), so probably literally answering this very question wouldn't move you forward. – egmont May 29 '20 at 21:21
  • My initial title was bad, he changed the title to "does not understand", I changed it to understands. The edits were helpful though, my english is not the best. – Csaba Mihaly May 29 '20 at 21:22
  • I just want to trick the program into thinking the terminal didn't change, if it's is possible somehow. It should be an option in the client app but I can't find one that does that. – Csaba Mihaly May 29 '20 at 21:26
  • "I just want to trick the program into thinking the terminal didn't change" – If the program thinks something different than the actual size, its display will fall apart. There is no way you could want that. The way to correct behavior is if the application always knows exactly how big the terminal is, and paints the contents accordingly. – egmont May 29 '20 at 21:42

1 Answers1

3

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.

bk2204
  • 3,571
  • 5
  • 9