possible bug with xsh.Screen.CurrentRow [3]
possible bug with xsh.Screen.CurrentRow
Wednesday, March 29, 2017 11:26 AM - jsanagustin
Hello,
I haven't been able to discern a pattern but I've found that there are times where xsh.Screen.CurrentRow incorrectly reports as 5024, when there's no way that the current session has 5000+ lines. Then, if the script were to cause additional lines to be generated in the terminal, xsh.Screen.CurrentRow still reports 5024. So far, when this bug pops up, I don't believe I've seen it return any number other than 5024.
Using 'Reset Terminal' via the popup menu fixes this; in other words, xsh.Screen.CurrentRow will then report the proper row number.
FWIW, my scripts are javascript.
Program Ver. : Xshell 5
I haven't been able to discern a pattern but I've found that there are times where xsh.Screen.CurrentRow incorrectly reports as 5024, when there's no way that the current session has 5000+ lines. Then, if the script were to cause additional lines to be generated in the terminal, xsh.Screen.CurrentRow still reports 5024. So far, when this bug pops up, I don't believe I've seen it return any number other than 5024.
Using 'Reset Terminal' via the popup menu fixes this; in other words, xsh.Screen.CurrentRow will then report the proper row number.
FWIW, my scripts are javascript.
Program Ver. : Xshell 5
Re: possible bug with xsh.Screen.CurrentRow
Tuesday, April 11, 2017 6:10 PM - jsanagustin
Hello! Any chance someone's reviewed this?
Thanks!
Thanks!
Re: possible bug with xsh.Screen.CurrentRow
Wednesday, April 12, 2017 1:30 AM - Henry
I have used this function over 5024 rows.
I tried over 60000. It worked well.
Check if your scroll buffer size is limited under 5024.
I tried over 60000. It worked well.
Check if your scroll buffer size is limited under 5024.
Re: possible bug with xsh.Screen.CurrentRow
Wednesday, April 12, 2017 6:09 PM - jsanagustin
Good point Henry. The behavior is indeed related to the buffer size setting. I increased my limit from 5000 to 6000, and now when this "unexpected" behavior occurs, xsh.Screen.CurrentRow reports 6024. It seems that this is the buffer size limit + the terminal height (my terminal height is shown as 25).
Sequence of events:
Filled buffer to beyond 6000 lines...
-Ran script and xsh.Screen.CurrentRow reports 6024.
-Reset terminal and xsh.Screen.CurrentRow reports 6000.
-Caused two lines to print, ran script, and xsh.Screen.CurrentRow reports 6002.
-Caused about 50 lines to print, ran script, and xsh.Screen.CurrentRow reports 6024.
-Caused 1 line to print, ran script, and xsh.Screen.CurrentRow still reports 6024.
-Cleared the scrollback buffer, and (as one would expect) xsh.Screen.CurrentRow reports 0.
So it seems the xsh.Screen.CurrentRow is likely doing what it should, however this poses a problem for a script that gets the current row, sends some commands, gets the current row, and reads what's between those rows. If the first "get" and the second "get" is the same number, then there won't be anything to read.
The quick fix, as I see it, would be to check if the row numbers are the same. If so, then present a dialog to the user to clear the scrollback and rerun the script.
Don't suppose it would be possible to expose a way for a script to clear the scrollback??
Sequence of events:
Filled buffer to beyond 6000 lines...
-Ran script and xsh.Screen.CurrentRow reports 6024.
-Reset terminal and xsh.Screen.CurrentRow reports 6000.
-Caused two lines to print, ran script, and xsh.Screen.CurrentRow reports 6002.
-Caused about 50 lines to print, ran script, and xsh.Screen.CurrentRow reports 6024.
-Caused 1 line to print, ran script, and xsh.Screen.CurrentRow still reports 6024.
-Cleared the scrollback buffer, and (as one would expect) xsh.Screen.CurrentRow reports 0.
So it seems the xsh.Screen.CurrentRow is likely doing what it should, however this poses a problem for a script that gets the current row, sends some commands, gets the current row, and reads what's between those rows. If the first "get" and the second "get" is the same number, then there won't be anything to read.
The quick fix, as I see it, would be to check if the row numbers are the same. If so, then present a dialog to the user to clear the scrollback and rerun the script.
Don't suppose it would be possible to expose a way for a script to clear the scrollback??
Previous views: 694