Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: persistent xterm sessions



 Derek Martin wrote: 
> Tom Metro wrote: 
>> I've noticed when I use screen inside an xterm on 
>> Ubuntu, screen breaks xterm's scrollback buffer. 
> 
> Presumably this is because the output of man is paged by the less 
> command. 

Yes, I assumed that was the underlying trigger. 

Though I incorrectly stated the problem before. When using screen, 
scrollback via the xterm is broken always, not just when viewing a man 
page. When you run screen inside gnome-terminal the scrollbar behaves 
perpetually as if you've never seen more than one screen of data. 

The man page issue can be observed without involving screen, which is 
what I was remembering. 


> Along with some other screen-oriented programs, less has the 
> ability to use a terminal's alternate screen (if it has one, xterm and 
> friends do). 

That would make sense. 


> This is set in xterm with a resource: 
> XTerm.vt100.titeInhibit:  true 

Is there a way to specify that as a command line option to 
gnome-terminal, or do I need to mess with the X resource database? 

A simple -X option set via the LESS environment variable fixes the less 
behavior. However I didn't see anything similar among the command line 
options for screen. I also didn't see a command line option for 
gnome-terminal that might cause it to ignore this kind of terminal control. 

While looking at the command line options for gnome-terminal I see it 
supports a bunch of settings for session management, like setting a 
session ID and restoring a specific session. However it does not appear 
that anything unique to a particular gnome-terminal window (other than a 
window ID) is exposed via an environment variable. But I'm guessing the 
info can probably be extracted from an X resource. 

Ideally, I'd rather let GNOME do the high-level session management and 
just supplement that with some scripting to restore command history and 
maybe scrollback. This should be doable if the script can extract some 
identifier that is unique to a window, and persistent across sessions. 
(I'm assuming window ID is like a process ID and just a sequential 
number that resets when X is restarted, so that won't work.) 

  -Tom 

-- 
Tom Metro 
Venture Logic, Newton, MA, USA 
"Enterprise solutions through open source." 
Professional Profile: http://tmetro.venturelogic.com/

-- 
This message has been scanned for viruses and 
dangerous content by MailScanner, and is 
believed to be clean. 

_______________________________________________ 
Discuss mailing list 
[hidden email] 
http://lists.blu.org/mailman/listinfo/discuss
 


BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org