Welcome to the VanDyke Software Forums

Join the discussion today!


Go Back   VanDyke Software Forums > General

Reply
 
Thread Tools Display Modes
  #1  
Old 09-21-2005, 06:32 PM
ChodTheWacko ChodTheWacko is offline
Registered User
 
Join Date: Sep 2005
Posts: 9
Problem with resize, vi, and tabs

Hello,

I haven't been able to nail down an exact test case, but this happens a couple times a day:

I have multiple tabs open to the same machine.
Currently using Hpux itanium, but it happens on any unix machine as far as I can tell. vt00 terminal type, on resize: synchronize view to size.

If I have multiple tabs, and I resize the window, then some of the background windows have vi problems.

if I open a file in vi, it shows me some incorrect screen output. (it seems to be a random set of lines from the scrollback). If I hit a key, it refreshes the screen and it looks fine. If I page up/page down, I get junk output till I hit another key. It does scroll up and down correctly.

The problem doesn't correct if I do 'edit -> reset', and I basically have to open a new CRT window and reopen my tabs. It doesn't always happen but it is pretty annoying when it does.

Just an FYI post - i'll remember to log the session next time this happens.
It always seems like it isn't sending a refresh signal correctly.

Oh, this happened with the first crt 5 beta, securecrt 5.0.1, and
secureCRT 5.0.3 which I just pulled down.

- Frank
Reply With Quote
  #2  
Old 09-22-2005, 04:31 PM
Maureen's Avatar
Maureen Maureen is offline
VanDyke Product Director
 
Join Date: Feb 2004
Location: Albuquerque, NM
Posts: 1,606
Frank,

Thanks for posting. There's some additional information that would help us track this down:

- When you do the resize, are you making the window bigger or smaller, or does it matter?
- Just to make sure I understand, are you starting vi before or after you do the resize?
- When you get in this state, please type "stty -a" at the prompt to see if the rows and columns the system is using matches what SecureCRT shows in the status bar.

Maureen
Reply With Quote
  #3  
Old 09-24-2005, 10:14 AM
FuzzyFox's Avatar
FuzzyFox FuzzyFox is offline
Registered User
 
Join Date: Feb 2005
Location: Dallas, TX
Posts: 59
Send a message via ICQ to FuzzyFox Send a message via AIM to FuzzyFox Send a message via MSN to FuzzyFox Send a message via Yahoo to FuzzyFox
Quote:
Originally Posted by ChodTheWacko
Oh, this happened with the first crt 5 beta, securecrt 5.0.1, and
secureCRT 5.0.3 which I just pulled down.
Do you mean to imply that this didn't happen with older versions of SecureCRT, or do you mean that these are the only versions you tried?

HP-UX is troublesome. It is both a SYSV and BSD Unix derivative, so it often makes use of features from both worlds. For instance, the environment variables LINES and COLUMNS are used in the SYSV world, to tell programs (like vi) how many rows and columns the screen has. BSD uses tty attributes (viewed using stty size) to communicate those same settings.

HP-UX uses both methods, so it is often unclear which method a program is using to read the terminal size. And in fact, user programs (such as vi) also often use both methods, so it is unclear which source they will use for information, and in what order they will try.

Before and after resizing your terminal, you should run the following commands:
Code:
echo $LINES $COLUMNS
stty size
The two numbers will probably be the same before the resize, but are they the same after the resize?

Try this experiment:

If running ksh: unset LINES COLUMNS
If running csh: unsetenv LINES COLUMNS

Then try running vi again, and see if the problem continues.

You see, when you resize your terminal, the new size is communicated properly to sshd running on HP-UX, and since sshd has control of the master side of the pseudo-terminal, it is able to update the tty settings (shown by stty size) without any trouble. However, the LINES and COLUMNS variables are stored in the child shell process, quite out of the reach of sshd's control. The best that sshd can do (and does), is to send a SIGWINCH signal to the shell process (group), telling it that the window size has changed. However, not all shells know what to do with this signal, so the environment variables may not get updated.

In this case, it may make a difference which shell you happen to use. If you use an older shell like sh or csh, you might well run into this problem. But, perhaps a newer shell such as ksh or tcsh will handle this issue correctly.
Reply With Quote
  #4  
Old 10-03-2005, 05:37 PM
ChodTheWacko ChodTheWacko is offline
Registered User
 
Join Date: Sep 2005
Posts: 9
I will try the above.

It happens every now and then still, but I'm trying to nail down what exactly I'm doing prior to that. (I work in Tech support too). I'll let you know.

I have never had a problem with versions prior to 5.
In fact, when I resize or whatever, the window I am currently viewing never has a problem. It's one of the tabbed windows that gets screwy. It's like whatever is being sent to the current window isn't being sent to the other windows also, and so one of them gets out of sync.
Reply With Quote
  #5  
Old 10-03-2005, 07:54 PM
FuzzyFox's Avatar
FuzzyFox FuzzyFox is offline
Registered User
 
Join Date: Feb 2005
Location: Dallas, TX
Posts: 59
Send a message via ICQ to FuzzyFox Send a message via AIM to FuzzyFox Send a message via MSN to FuzzyFox Send a message via Yahoo to FuzzyFox
From what you just posted, it sounds like you're saying you can't make this happen in a repeatable fashion. That is strange... Computers usually follow laws of logic, even when they are screwing up.

I wrote a little test program to watch for the SIGWINCH signal, and even when I run it in multiple tabs while resizing the window, every tab receives the signal just as it should.

I wonder if you're doing something more involved, such as you ssh from your target system, to another system, and then the signal somehow gets dropped along the chain? I tested the case of ssh from one system to another, and the SIGWINCH still makes it through. Maybe if you use telnet or rlogin instead of ssh, the signal might fail to go through? I can't test those conditions, alas.
Reply With Quote
  #6  
Old 10-05-2005, 01:09 PM
ChodTheWacko ChodTheWacko is offline
Registered User
 
Join Date: Sep 2005
Posts: 9
AH HA

I got it to repo.
I can make the problem happen at will now.
I managed to get the resize out of the picture too.



Here's the steps:

1) open a window to a machine, log in. it happens on solaris too.
add returns to add some scrolling room.

2) clone it, log in again.
hit returns to add some scrolling room in window #2

3) In window #2 drag the scrollbar up (not all the way up though)
4) hit the tab to go back to window #1
5) hit the tab to go back to window #2.
The scrollbar should still be 'up'
6) hit return in window #2 - the scrollbar shifts back to the bottom where you are typing.
7) start vi in window #2 - the screen jumps back up to where the tab was in #6.
8) hit any key: vi refreshes and the scrollbar pops back down.

page up and page down are screwed up after this so it's very very annoying.

Luckily this means I have a workaround: drag #2 back to the bottom, and then tab in and out of another window.
Reply With Quote
  #7  
Old 10-12-2005, 11:12 AM
Maureen's Avatar
Maureen Maureen is offline
VanDyke Product Director
 
Join Date: Feb 2004
Location: Albuquerque, NM
Posts: 1,606
Sorry for the slow reponse. Thank you very much for posting the steps to reproduce this problem. Using your steps, I was able to get it to happen on a Redhat Linux machine. I will log an issue in our development database so that we can look into it. I'll let you know what we find out.

Maureen
Reply With Quote
  #8  
Old 10-25-2005, 05:52 PM
Maureen's Avatar
Maureen Maureen is offline
VanDyke Product Director
 
Join Date: Feb 2004
Location: Albuquerque, NM
Posts: 1,606
This has been fixed in SecureCRT 5.1, which is in alpha testing. Please send an e-mail to me at Maureen.Jett if you would like to try a version with the fix.

Maureen
Reply With Quote
Reply


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -6. The time now is 04:33 PM.