Regarding some recent discussion of getting a convenient scrollback buffer working with screen in an Xterm: I notice that Ctrl-PgUp works fine in Putty under windows.
Jonathan Hutchins wrote:
Regarding some recent discussion of getting a convenient scrollback buffer working with screen in an Xterm: I notice that Ctrl-PgUp works fine in Putty under windows.
Ctrl+PgUp/PgDn in PuTTY, IIRC, is used to scroll back in PuTTY's own buffer. You can also do some variation of this in most of the XTerm emulators available on Linux when running Screen. Due to my limited knowledge of how the specific protocol works, I can only guess, but I think that works because new lines in the buffer are appended to the bottom of the screen and old lines are pushed off the top.
In Screen the official scroll back method is Ctrl+A ESC then PgUp and PgDn. ESC to exit scroll mode. You can also mark for copy and paste in this mode.
On Sun, Nov 28, 2004 at 10:30:07AM -0600, Jason Clinton wrote:
In Screen the official scroll back method is Ctrl+A ESC then PgUp and PgDn. ESC to exit scroll mode. You can also mark for copy and paste in this mode.
It took me a while to get up to speed to using the copy-and-paste functionality. But I kept getting to machines where the mouse was malfunctioning (over a kvm switch, for instance), or X was running and I couldn't get it to share easily (or at all) with gpm (KNOPPIX live CD on some hardware), or whatever, so I finally learned it.
Yet another arrow in screen's mind-blowing quiver of unobtrusive yet powerful functionality. I can't recommend it enough.
Ooookaaay.
Once again, I think we've gone off on tangents without attention to the original thread.
The problem is that when running screen in a terminal window, screen tends to intercept the scrollback buffer. This means that whatever you've configured for the terminal program is often irrelevant, as is the terminal program's normal scrollback function.
While the ability to use screen's buffer-edit function does give you a scrollback, it also transforms the expected, accustomed behavior of the terminal; the ease of scrolling back with a mouse wheel or familiar keys.
Somehow, putty overcomes this, and manages to buffer and allow scrollback even within screen sessions. Wouldn't it be nice if common Linux/Xwindows terminal programs did as good a job of integrating with this common Linux utility?
Jonathan Hutchins wrote:
The problem is that when running screen in a terminal window, screen tends to intercept the scrollback buffer. This means that whatever you've configured for the terminal program is often irrelevant, as is the terminal program's normal scrollback function.
While the ability to use screen's buffer-edit function does give you a scrollback, it also transforms the expected, accustomed behavior of the terminal; the ease of scrolling back with a mouse wheel or familiar keys.
Somehow, putty overcomes this, and manages to buffer and allow scrollback even within screen sessions. Wouldn't it be nice if common Linux/Xwindows terminal programs did as good a job of integrating with this common Linux utility?
Actually, I'm running screen under PuTTY right now, and while it does in fact scrollback, it does _NOT_ scrollback over the currecnt screen session, but rather it scrolls back to what was on the tty before I started screen.
Note that the middle command is where I connected to the screen session. I suppose that xterm could be made to emulate this behaviour, but I don't see how usefuel it is.
Scrolled back half-height in my PuTTY session: ============================================================================ -rw-rw-r-- 1 hald hald 8019 Nov 19 11:12 x12_dict_inter_element.c.save -rw-rw-r-- 1 hald hald 7068 Nov 20 21:41 x12_dict_inter_element.o -rw-rw-r-- 1 hald hald 10107 Nov 21 17:34 x12_dict_inter_segment.c -rw-rw-r-- 1 hald hald 10107 Nov 19 11:11 x12_dict_inter_segment.c.save -rw-rw-r-- 1 hald hald 9884 Nov 20 21:41 x12_dict_inter_segment.o -rw-rw-r-- 1 hald hald 1442160 Nov 21 17:34 x12_dict_segment.c -rw-rw-r-- 1 hald hald 1442160 Nov 19 11:11 x12_dict_segment.c.save -rw-rw-r-- 1 hald hald 1281264 Nov 20 21:42 x12_dict_segment.o -rw-rw-r-- 1 hald hald 1507072 Nov 21 17:32 x12_dict_transaction.c -rw-rw-r-- 1 hald hald 1507072 Nov 21 12:24 x12_dict_transaction.c.save -rw-rw-r-- 1 hald hald 1271852 Nov 20 21:42 x12_dict_transaction.o -rwxrwxr-x 1 hald hald 147327 Nov 22 00:18 x12_pdf2c -rw-rw-r-- 1 hald hald 158040 Nov 25 11:11 x12_pdf2c.c -rw-rw-r-- 1 hald hald 147959 Nov 21 17:46 x12_pdf2c.c.final -rw-rw-r-- 1 hald hald 141628 Nov 22 00:18 x12_pdf2c.o -rw------- 1 hald hald 18530 Apr 4 2004 XML2002Paper.html -rwxrwxr-x 1 hald hald 2424130 Nov 21 00:41 xml_element -rw-rw-r-- 1 hald hald 4985 Nov 19 10:56 xml_element.c -rwxrwxr-x 1 hald hald 1043809 Nov 21 00:41 xml_segment -rw-rw-r-- 1 hald hald 6156 Nov 19 10:32 xml_segment.c -rwxrwxr-x 1 hald hald 933958 Nov 21 00:40 xml_transaction -rw-rw-r-- 1 hald hald 7104 Nov 19 11:00 xml_transaction.c -rw-rw-r-- 1 hald hald 21 Nov 19 13:12 xxq.c [hald@apollo x12]$ screen -r
[hald@apollo ~]$ cd projects/x12/ [hald@apollo x12]$ gdb ./xml_transaction GNU gdb Red Hat Linux (6.1post-1.20040607.43rh) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db library "/lib/tls/libthread_db.so.1".
(gdb) break 41 Breakpoint 1 at 0x8048999: file xml_transaction.c, line 41. (gdb) r Starting program: /home/hald/projects/x12/xml_transaction [Thread debugging using libthread_db enabled] [New Thread -151071040 (LWP 2546)] [Switching to Thread -151071040 (LWP 2546)]
Breakpoint 1, main (argc=1, argv=0xfefece44) at xml_transaction.c:41 41 if(t->functional_group_identifier != NULL) ============================================================================
-- Hal Duston
On Tue, November 30, 2004 10:29 am, Hal Duston said:
Actually, I'm running screen under PuTTY right now, and while it does in fact scrollback, it does _NOT_ scrollback over the currecnt screen session, but rather it scrolls back to what was on the tty before I started screen.
Interesting. I was running the current version of putty (downloaded this weekend from http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html) on Windows XP.
Jonathan Hutchins [mailto:hutchins@tarcanfel.org] wrote:
On Tue, November 30, 2004 10:29 am, Hal Duston said:
Actually, I'm running screen under PuTTY right now, and while it does in fact scrollback, it does _NOT_ scrollback over the currecnt screen session, but rather it scrolls back to what was on the tty before I started screen.
Interesting. I was running the current version of putty (downloaded this weekend from http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html) on Windows XP.
I just updated PuTTY here to 0.56, and I still see the same behaviour as before. The way that screen, (or vi, less, etc.) communicates with PuTTY or xterm (or even the console TTY as this is all part of PuTTY's and xterm's console emulation), is with terminfo escape codes. There exists a single alternate screen, and escape codes to facilitate switching between that alternate and the primary screen only. I wouldn't have expected any other behaviour from either xterm or PuTTY, as "doing what seems correct" would require the xterm or PuTTY client to maintain an unlimited number of scrollback areas, one for each potential screen.
-- Hal Duston
Jonathan Hutchins wrote:
Interesting. I was running the current version of putty (downloaded this weekend from http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html) on Windows XP.
In case anyone is interested, there's a UNIX port of PuTTY available on the same page.
On a related note, has anyone run across any terminal apps that interact more closely with the shell? The closest I've found is XMLTerm (http://xmlterm.sourceforge.net/) but the project hasn't been active since 2000.
Gerald Combs wrote:
On a related note, has anyone run across any terminal apps that interact more closely with the shell? The closest I've found is XMLTerm (http://xmlterm.sourceforge.net/) but the project hasn't been active since 2000.
As in shell expressions may manipulate the terminal window's properties and GUI settings for shell behavior like the prompt and command-key style and certain environment variables? Like escape codes but less cryptic and more robust?
Jason Clinton wrote:
As in shell expressions may manipulate the terminal window's properties and GUI settings for shell behavior like the prompt and command-key style and certain environment variables? Like escape codes but less cryptic and more robust?
Yes. And the communication between the terminal and shell needs to be bidirectional. I want my terminal app to be able to get _and_ put commands, environment variables, working directories, and anything else that might be useful.
On Tue, 2004-11-30 at 07:53 -0600, Jonathan Hutchins wrote:
Ooookaaay.
Once again, I think we've gone off on tangents without attention to the original thread.
Tangents? Everyone has been RTFM for you, and given the solution.
The problem is that when running screen in a terminal window, screen tends to intercept the scrollback buffer. This means that whatever you've configured for the terminal program is often irrelevant, as is the terminal program's normal scrollback function.
How is this to happen? You have forgotten the purpose for using screen in the first place. To be able to detach, and attach to a running terminal.
How are you going to page up/down in xterms buffer when you detach?
You can also run multiple screen windows (ctrl-a c & ctrl-a n) so which buffer is xterms page up/down suppose to scroll?
Hence the need for screen to have its own buffer.
While the ability to use screen's buffer-edit function does give you a scrollback, it also transforms the expected, accustomed behavior of the terminal; the ease of scrolling back with a mouse wheel or familiar keys.
Somehow, putty overcomes this, and manages to buffer and allow scrollback even within screen sessions. Wouldn't it be nice if common Linux/Xwindows terminal programs did as good a job of integrating with this common Linux utility?
Quickly checking the screen mailing list, turned up this link http://www4.informatik.uni-erlangen.de/~jnweiger/screen-faq.html
Look at Q:My xterm scrollbar does not work with screen. For how to do what you want, even though the value of it is limited, see my comments above.
Kclug mailing list Kclug@kclug.org http://kclug.org/mailman/listinfo/kclug
On Tuesday 30 November 2004 02:49 pm, Bill Cavalieri wrote:
The problem is that when running screen in a terminal window, screen tends to intercept the scrollback buffer. This means that whatever you've configured for the terminal program is often irrelevant, as is the terminal program's normal scrollback function.
How is this to happen?
(Meaning, aparantly, "How is normal scrollback functionality to be maintained when using multiple screen sessions?")
That's easy: Just like putty does it.
Yes, each session in screen needs it's own buffer. No, I'm not sure how putty achieves this.
I'm also not able to check to make sure putty works with multiple screen sessions, if at all. I do know that my default xterm will not scroll back with a _single_ screen session - the buffer indicator goes to 100% when I launch screen.
I have read the manuals, which is why I find it frustrating when people on the list just quote man pages at me regarding this. They don't actually address the problem.
Thank YOU very much though, you found the answer:
Place
termcapinfo xterm ti@:te@
in your .screenrc file.
(better yet in /etc/screenrc)
On Tue, 30 Nov 2004 17:19:45 -0600, Jonathan Hutchins hutchins@tarcanfel.org wrote:
(Meaning, aparantly, "How is normal scrollback functionality to be maintained when using multiple screen sessions?")
That's easy: Just like putty does it.
Might I be so bold as to suggest that if you want something that works like putty... use putty! Connect it to localhost if you must, but you'll have the functionality you want.
On Tue, 2004-11-30 at 17:19 -0600, Jonathan Hutchins wrote:
On Tuesday 30 November 2004 02:49 pm, Bill Cavalieri wrote:
The problem is that when running screen in a terminal window, screen tends to intercept the scrollback buffer. This means that whatever you've configured for the terminal program is often irrelevant, as is the terminal program's normal scrollback function.
How is this to happen?
(Meaning, aparantly, "How is normal scrollback functionality to be maintained when using multiple screen sessions?")
That's easy: Just like putty does it.
Your still not getting it, if you disconnect from screen window (ctrl-a d), and then reconnect, how does putty scroll the buffer?
Answer is it doesn't, it will only scroll what happend when you were connected to screen window. How is that useful? When I'll start a job that will take 10hrs to complete, and want to see what happened when I disconnected, and reconnet to screen window at home?
Yes, each session in screen needs it's own buffer. No, I'm not sure how putty achieves this.
It doesn't if you start a screen session, and then a second one with ctrl-a c, what is happening on the first screen window session is not going to be in putty's buffer, past when you switched screen windows, a lot could have gone by, only way to know this is to ctrl-a esc, and look at screen's buffer, not putty's.
I'm also not able to check to make sure putty works with multiple screen sessions, if at all. I do know that my default xterm will not scroll back with a _single_ screen session - the buffer indicator goes to 100% when I launch screen.
That is because you are confusing screen with xterm, they are not the same. xterm is a terminal, screen is a (cut from man page) "Screen is a full-screen window manager that multiplexes a physical terminal between several processes (typically interactive shells)."
I have read the manuals, which is why I find it frustrating when people on the list just quote man pages at me regarding this. They don't actually address the problem.
Thank YOU very much though, you found the answer:
Place
termcapinfo xterm ti@:te@
in your .screenrc file.
(better yet in /etc/screenrc)
Well all the answers found so far have been in the man pages. Along with explanation as to what screen is.
And the whole scrolling thing, is not a screen issue anyways, its xterm's, which I how I found that link. xterm does not allow scrolling when the alternate text buffer is uses, ie other applications like vi, nano, etc..
Kclug mailing list Kclug@kclug.org http://kclug.org/mailman/listinfo/kclug
I used a lot more words to say it, but the info at the bottom was present in my quotation of the Fine Manual. I later went on to describe the salient points of interaction between terminal window and program, i.e. screen. I suppose I could learn to read minds, you could give me my own login and I could do stuff for you, but what would be the point in that? I try to give clear answers, quote where appropriate, give an URL to my source and flesh out unspoken details. All this so that I and others may learn more. Where's that link to the Jargon File on asking good questions?
Jonathan Hutchins wrote:
On Tuesday 30 November 2004 02:49 pm, Bill Cavalieri wrote:
The problem is that when running screen in a terminal window, screen tends to intercept the scrollback buffer. This means that whatever you've configured for the terminal program is often irrelevant, as is the terminal program's normal scrollback function.
(Meaning, aparantly, "How is normal scrollback functionality to be maintained when using multiple screen sessions?")
That's easy: Just like putty does it.
Yes, each session in screen needs it's own buffer. No, I'm not sure how putty achieves this.
I'm also not able to check to make sure putty works with multiple screen sessions, if at all. I do know that my default xterm will not scroll back with a _single_ screen session - the buffer indicator goes to 100% when I launch screen.
I have read the manuals, which is why I find it frustrating when people on the list just quote man pages at me regarding this. They don't actually address the problem.
Thank YOU very much though, you found the answer:
Place
termcapinfo xterm ti@:te@
in your .screenrc file.
(better yet in /etc/screenrc)
I thought this might be appropriate for the topic;
http://applications.linux.com/applications/04/11/29/1651257.shtml?tid=47&...
Regards, Steven
On Tue, 30 Nov 2004 20:00:39 -0600, Brian Kelsay bkelsay@comcast.net wrote:
I used a lot more words to say it, but the info at the bottom was present in my quotation of the Fine Manual. I later went on to describe the salient points of interaction between terminal window and program, i.e. screen. I suppose I could learn to read minds, you could give me my own login and I could do stuff for you, but what would be the point in that? I try to give clear answers, quote where appropriate, give an URL to my source and flesh out unspoken details. All this so that I and others may learn more. Where's that link to the Jargon File on asking good questions?
Jonathan Hutchins wrote:
On Tuesday 30 November 2004 02:49 pm, Bill Cavalieri wrote:
The problem is that when running screen in a terminal window, screen tends to intercept the scrollback buffer. This means that whatever you've configured for the terminal program is often irrelevant, as is the terminal program's normal scrollback function.
(Meaning, aparantly, "How is normal scrollback functionality to be maintained when using multiple screen sessions?")
That's easy: Just like putty does it.
Yes, each session in screen needs it's own buffer. No, I'm not sure how putty achieves this.
I'm also not able to check to make sure putty works with multiple screen sessions, if at all. I do know that my default xterm will not scroll back with a _single_ screen session - the buffer indicator goes to 100% when I launch screen.
I have read the manuals, which is why I find it frustrating when people on the list just quote man pages at me regarding this. They don't actually address the problem.
Thank YOU very much though, you found the answer:
Place
termcapinfo xterm ti@:te@
in your .screenrc file.
(better yet in /etc/screenrc)
Kclug mailing list Kclug@kclug.org http://kclug.org/mailman/listinfo/kclug
-
Bill Cavalieri -
Brian Kelsay -
D. Joe Anderson -
Gerald Combs -
Hal Duston -
Jason Clinton -
Jonathan Hutchins -
Monty J. Harder -
Steven Hildreth