4

This has been annoying me for ages. Even though I use a modern terminal emulator and most CLI programs, such as less and vim, are able to use the alternate screen adequately (i.e. entering it on startup and leaving it on exit), some are reluctant to do so. Rogue programs include top, screen and dialog.

When they start, these programs clear the contents of the window (i.e. the last N lines where N is the height of the terminal window). When they exit, some (top) leave their last state visible, while others (screen) clear the screen again. In all cases, the last N lines of scrollback buffer have been overwritten.

I checked this on various machines over time, and in various terminal emulators, including xcfce4-terminal, urxvt and screen (the alternate screen of which being properly enabled, using :altscreen on). Hence I do not think it is a problem with my terminal, I rather believe it is the built-in behavior of these programs (at least unpatched, as they are distributed in Archlinux).

So my questions are:

  1. Why do these programs behave like this? I guess there are good reasons for it?
  2. How can I work around it? Currently, I am using dumb wrapper scripts like the one below, but maybe there is a cleaner way?

    # save this as: ~/bin/top
    
    if [ -t 1 ]; then  # only use alt screen if output is a terminal
        tput smcup  # toggle alt screen on
        /usr/bin/top "$@"
        tput rmcup  # toggle alt screen off
    else
        /usr/bin/top "$@"
    fi
    
muru
  • 72,889
Maëlan
  • 426
  • 2
  • 16
  • With altscreen on in my ~/.screenrc I don't have such an issue. Have you considered updating the version of screen that's installed? Seems like this is more than one question, also. – Wildcard Aug 02 '19 at 23:13
  • As I said, I have seen the same behavior for years and with several different terminal emulators, and, besides, as an Archlinux user, I am running recent versions of all programs. So it cannot be because of outdated programs, nor because of screen’s “inner” configuration specifically. – Maëlan Aug 03 '19 at 00:04
  • 1
    So then it seems you have several questions mixed together, and you don't want to consider applying patches from upstream. Please edit your question to clarify your exact question. The "better way" in my opinion would be to install current versions of the programs giving you trouble, but it's pretty broad right now. – Wildcard Aug 03 '19 at 00:06
  • Well, I just said that I already have the current versions of all involved programs. I am indeed not interested in patching them myself. I have many reasons not to do that, the first of which being that I don’t know why it is that way, and I guess that there are good reasons for it. Which is precisely why I am asking my first question. I highlighted my questions as you requested. I agree that they are pretty vague. I’m not sure what would be a “cleaner” way but, for example, an option I missed, or a standard env var USE_ALTSCREEN of which I would have never heard before… would qualify. – Maëlan Aug 03 '19 at 00:34
  • Ah, I misread, I thought you said you DON'T have recent versions of all programs. My apologies! – Wildcard Aug 03 '19 at 00:52
  • 2
  • Some people hate the alternate screen feature and not only they don't care to fix programs to work with it, but also go out of their way to break it ;-) 2. patch the corresponding programs. For 2., notice that the switch should also be performed when the program is stopped/continued (eg. with ^Z), not only upon starting/exiting. That's something your wrapper fails to do.
  • –  Aug 03 '19 at 01:51
  • 1
    Instead of 2., you should also consider using alternatives (htop, whiptail, tmux). Notice that simple programs which are using ncurses in the regular way (initscr()/endwin()) don't have to do anything special; the ncurses library takes care of everything. –  Aug 03 '19 at 02:17
  • @mosvy, thanks for your input! I was suspecting that it may be a “political” issue, thanks for confirming it. I will sure look into these alternatives, of which I have already heard as “superior” replacements (more modern, better behaved, better defaults, easier to use…). I think that I will take your comments as my answer, even though this is a negative conclusion. – Maëlan Aug 07 '19 at 12:03
  • On the stop/continue issue, well spotted. Unfortunately, handling SIGSTOP/SIGCONT from a shell script does not seem easy, if feasible at all. All methods I can think of imply starting the wrapped program in the background, which is not possible since the said program is interactive (for instance, /usr/bin/top & fails with the error message “failed tty set: Interrupted system call”). So I guess I will stick with this partial solution. Even though top_wrapper.sh & has strange effects… – Maëlan Aug 07 '19 at 12:08
  • Yes, it would be much easier to patch the program rather than to wrap it using a shell script. I think a better approach would be to write your wrapper in C, so that you can use waitpid() to determine when it stops and continues. – Toby Speight Aug 09 '19 at 07:34