Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I was trying to use different screen buffer for my script using tput. Below is small script that I am running.

tput smcup
clear
dialog --yesno "Do you want to continue?" 0 0
rc=$?
clear
tput rmcup
if [ "${rc}" == "0" ]; then
  echo Yes
else
  echo No
fi

After the script is finished executing there is a blank part on the screen(as shown below in the image) which is equal to the rows occupied by the prompts before running the script.Ideally tput should have switched to second screen buffer and after executing it should have come back to the first screen buffer. The script switches to the second screen but after coming back it leaves a blank space which shouldn't be there .

enter image description here

share|improve this question
    
please add info like OS, version of dialog, terminal, what command you run with --keep-tite and what happens then... so people don't have to look through all the comments to get the full picture. – Stéphane Chazelas Mar 14 '13 at 20:31

It's an issue with the dialog implementation from http://invisible-island.net/dialog/dialog.html.

On startup, it does a smcup + rmcup by itself, I beleive because ncurses initialisation routine does the smcup and dialog wants to cancel that. So if you do your smcup beforehand, it will have no effect, because the rmcup will cancel it.

A work around is to add the --keep-tite option which tells it not to do that, so dialog will do the smcup on start and rmcup on exit like other ncurses applications if the terminal supports it.

From your comments, you seem to have another problem: you're in a terminal that doesn't support an alternative screen, so whatever you do, you won't be able to use that alternate screen as it doesn't exist.

What you could do though is either use a different terminal that has an alternate screen like putty or the Unix ones from Cygwin on Cygwin's X Server. Or run an X terminal on the remote server to connect to and display on your X Server. Or run a terminal-based terminal emulator inside your terminal that supports an alternate screen like GNU screen.

share|improve this answer
    
output of tput smcup | od -tc is 0000000 033 [ ? 1 0 4 9 h 0000010 and it doesn't switch to alternate screen and value of $TERM is xterm.Sorry I didn't understand about which implementation of dialog and --keep-tite didn't help.I use it like this dialog --keep-tite --yesno "Do you want to continue?" 0 0 – g4ur4v Mar 14 '13 at 10:33
    
uname -a gives Linux indlin534 2.6.18-238.12.1.el5 #1 SMP Sat May 7 20:18:50 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux and cat /etc/issue gives Red Hat Enterprise Linux Server release 5.6 (Tikanga) – g4ur4v Mar 14 '13 at 10:39
    
What's the terminal? It doesn't look like an xterm. Does it work in xterm or other terminals? Are you using screen or tmux inside that terminal? – Stéphane Chazelas Mar 14 '13 at 11:26
    
I am using mobaxterm software to connect to the server (ssh connection). – g4ur4v Mar 14 '13 at 12:29
    
I have tried putty with no luck.I don't think you are right when you say that the problem is with the terminal.I have tested tput smcup and rmcup without dialog and it works fine,as per my understanding the problem here is with dialog implementation.If my terminal doesn't have an alternate screen,how am I able to use vi and other such commands that require a similar implementation ? – g4ur4v Mar 14 '13 at 19:08

The problem is more complicated than suggested. Start with the script:

tput smcup
clear
dialog --yesno "Do you want to continue?" 0 0
rc=$?
clear
tput rmcup
if [ "${rc}" == "0" ]; then
  echo Yes
else
  echo No
fi

There is only one alternate screen (and you cannot treat it like a stack). The tput smcup (technically "start cursor-addressing mode") is often used with xterm and look-alikes to switch to the alternate screen. There is actually more than one control sequence implemented in xterm for this purpose (see Why doesn't the screen clear when running vi?), and some are not recognized by the look-alikes. In one of the comments, MobaXterm is said to be the actual terminal in this case. That is based on (uses code from) PuTTY, which happens to handle the 1049 code in MobaXterm's terminfo.

So...

  • the script switches to the alternate screen
  • it clears that (again: xterm clears the alternate screen on the previous step)
  • it runs dialog, still using the alternate screen.
  • when dialog exits, it sends the rmcup sequence, switching back into the normal screen, whose content will be the same as before the script began
  • then the screen is cleared. Normally that causes the cursor to be moved to the upper left of the screen and then cleared, but (see below)
  • finally, tput rmcup is used. That asks the terminal emulator to switch back from the alternate screen.

Since the terminal is already in normal mode, that last line could be interpreted in one of (at least) two ways:

  • it could be ignored
  • some part of the operations performed in the switch from alternate to normal mode might be executed.

In this case, it seems that the latter: part is performed. PuTTY (and in a quick check, xterm) restore the cursor position from the first use of tput smcup, because the prompt is in the middle of the screen (rather than at the top, where clear would leave it). OP noticed a gap because there were several commands already done in that window before running the script—the cursor returns to the original position, but the commands are gone because of the clear before the tput rmcup.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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