[Top][All Lists]

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

screen-256color terminfo entry?

From: cga2000
Subject: screen-256color terminfo entry?
Date: Tue, 09 May 2006 00:50:55 -0400
User-agent: Mutt/1.5.6+20040907i

I was planning to have screen start a few apps automatically using the
"screen" command in my .screenrc but I have run into a minor snag.

I currently run screen in an xterm with the 256 colors extension enabled
and the TERM variable pointing to xterm-256color terminfo entry before
screen is started. When I start screen manually it comes up with a
single default screen running a bash session. 

Now, after screen is started, if I issue the following:

$ echo $TERM

.. from the bash prompt, I am informed that the contents of the TERM
variable have been reset to 'screen'.

Now, since several applications appear to use the contents of the TERM
variable to decide whether they should enable the 256 color mode (vim
and elinks.. and mutt to some extent..) I have added the following to
my ~/.bashrc.

export TERM="xterm-256color"

This saves me the trouble of having to set/export the TERM variable
manually every time I create a new screens.

Although rather clumsy (I did add a test to verify I was not running
under a linux console.. but I have not have the time to try and figure
out something more elegant..) this does what I need and - so far - does
not appear to have any adverse effects where screen is concerned.

So in a nutshell, this is how I currently bring up my screen sessions:

. I start an xterm manually
. I start an instance of screen therein
. I hit "Ctrl-A C" - bash automatically sets TERM to xterm-256color
. I type "vim" at the prompt, hit <enter> & start vim
. I hit "Ctrl-A C" & manually start mutt
. I hit "Ctrl-A C" & manually start elinks.. etc.

This is both rather tedious and error prone - such as starting the apps
in the wrong order.. leaving out command-line flags etc.

This is why I thought I should look into automating this process.

The "snag" I ran into is that when I tried to replace the above by the
following lines at the end of my .screenrc:

screen -t bash /usr/bin/bash
screen -t vim  /usr/bin/vim
screen -t mutt /usr/bin/mutt
screen -t mutt /usr/bin/elinks

.. and fired up screen, well.. vim and mutt are now running directly
under screen, without the "intervening bash" - and so I have no way to
set the TERM variable to a value that would tell my three apps that they
should use the 256 available colors rather than the default 8/16..

As far as I can tell there is no mention of extended color support in
screen.. after all, screen only appears to have limited use for
colors (status/caption line..?) so said support may not be relevant
where screen proper is concerned. 

Now on the other hand, this is not the case for the applications
running under screen. So I was wondering if any one could advise a
simple strategy to address this frustrating issue.

Should I try to cook up a screen-256color terminfo..? Should I add
color-related terminfo entry to my .screenrc?

Needless to say, at least where vim is concerned, I could add another
kludge to my .vimrc to check whether I am running under "xterm with 256
color enabled + screen" - rather than "linux console + screen" for
instance and if the former.. make vim start in 256-color mode. But I'm
not sure there is an easy way to do this with elinks for instance.. and
in any case this is a rather inelegant solution.. and since it's more
complicated - no single control-point, more likely to break.. so I would
much prefer screen to be "transparent" in this respect and have the
different applications running under screen "believe" they are running
under a 256-color-enabled, so-to-speak..

Sorry about the verbosity of this post.

Any pointers/suggestions welcome.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]