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. cga _______________________________________________ screen-users mailing list [email protected] http://lists.gnu.org/mailman/listinfo/screen-users
