| All Forums |
Register |
Login |
Search |
Subscriptions |
My Profile |
Inbox |
| Tool Warehouse |
FAQs |
Resources |
Help |
Member List |
Address Book |
Logout |
|
|
RE: xterm colors in the 'Getting Started' forum
|
Logged in as: Guest |
| Users viewing this topic: none |
|
Login  |
|
|
 RE: xterm colors in the 'Getting Started' forum - Nov. 10, '05, 4:53:07 AM
|
|
|
jon493
Posts: 56
Joined: Oct. 14, '05,
Status: offline
|
The manual page for xterm (the newer one) states that it is the xterm program which sets the TERM and TERMCAP entries. This being the case, why is TERM set to xterm and not xterm-color by default? I am currently changing the TERM value on the fly by using a script to check for TERM=xterm and replace it with TERM=xterm-color. Although this solution works fine, it feels like a hack. I would like a better solution.
P.S. Can this be remedied by using the XTerm-color resource file instead of the default XTerm? I have been trying this but it doesn't seem to work (yet). Can someone tell me the proper way to do it (if it is the correct solution)?
|
|
|
|
|
RE: xterm colors in the 'Getting Started' forum - Nov. 10, '05, 6:39:41 AM
|
|
|
Rodney
Posts: 3142
Joined: Jul. 9, '02,
From: /Tools lab
Status: online
|
Yes, the manual page is correct. Xterm sets the environment variable TERM to "xterm".
That's the way it came.
The workaround is to test for the env var TERM equally "xterm" and if true then change TERM
to equal "xterm-color". This test being done in your "~/.profile" (ksh) and/or "~/.login" (csh).
With TERM set to "xterm" are you experiencing a problem?
|
|
|
|
|
RE: xterm colors in the 'Getting Started' forum - Nov. 10, '05, 6:53:05 AM
|
|
|
jon493
Posts: 56
Joined: Oct. 14, '05,
Status: offline
|
First of all, thanks for the reply. I don't have any problems with TERM=xterm (apart from no color!).
However, I am already using the workaround you describe, and getting desirable results (as I mentioned in my reply to the question in 'Getting Started'); but as I said, this leaves two 'loopholes':
1. TERMCAP entry is still unresolved - set to whatever xterm sets it to (which will probably not be for xterm-color, but for xterm). This could cause problems.
2. As I said, this solution feels like a hack. xterm should always set TERM=xterm-color and the corresponding TERMCAP, rather than user-level kludging. At most, a command-line option or an X-resource could be provided to use the b/w option. If this is the case, there most certainly is a bug in xterm.
3. The manual page also talks about using the XTerm-color resource file. This solution looks the most promising: if I can get it to work. The theory is that applications search for their resources in a directory specified by XAPPLRESDIR envir. var. However, on my system, XAPPLRESDIR contains 3 colon delimited directories. I seem to remember that (at least for X11R5) only a single directory may be specified. Is this the problem? I have not tweaked these settings yet, so I am still trying.
|
|
|
|
|
RE: xterm colors in the 'Getting Started' forum - Nov. 10, '05, 12:39:47 PM
|
|
|
Rodney
Posts: 3142
Joined: Jul. 9, '02,
From: /Tools lab
Status: online
|
> First of all, thanks for the reply. I don't have any problems with TERM=xterm (apart from no color!).
I think I see the problem.
I'm running xterm and get colour with TERM=xterm.
It has to do with the aliasing in the terminfo source file that results in the database.
I suspect that you do not have the newer libncurses package installed. A newer
terminfo database gets installed. The one that ships with SFU makes reference to a non-colour
base while the newer one references a colour version.
So try installing the libncurses package.
|
|
|
|
|
RE: xterm colors in the 'Getting Started' forum - Nov. 15, '05, 3:28:07 AM
|
|
|
jon493
Posts: 56
Joined: Oct. 14, '05,
Status: offline
|
> I'm running xterm and get colour with TERM=xterm.
Please check this -- are you getting colour with ls -colour etc. or are you getting colour automatically with lynx or vim? Vim also has a workaround for this kind of problem (see :help xterm-color in vim). Please make sure that you are not using it. I get colour with ls etc. Its only with programs like lynx or vim that I get this problem.
> I suspect that you do not have the newer libncurses package installed.
I do have the newer ncurses package (5.4). I've had it for a long time now.
Anyway, I did some further research myself:
As I said, I was most keen on trying the XAPPLRESDIR and XFILESEARCHPATH route. As directed in the manual page for xterm, I included the
*customization: -color
line in my .Xdefaults file, and then proceeded further.
I found out the following:
1. About the 3 directories in my XAPPLRESDIR -- SORRY [:-(]
I did have 3 directories, but that was the the handiwork of my evil twin. I am now quite sure that you need to -- you must -- have only one directory as XAPPLRESDIR, even in X11R6. The said directory path must even include the trailing slash, as in:
XAPPLRESDIR=/usr/X11/lib/X11/app-defaults/
or else it will not function. This is because the defaults files' paths are obtained simply by concatenating the filename to the value of XAPPLRESDIR without adding a trailing slash to XAPPLRESDIR.
This instantly opened up a line of investigation. After modifying my .Xdefaults file, I restarted xterm. No effect. I restarted my X server and then restarted xterm. Still no effect. Probably xterm was not finding the XTerm-color defaults file, and was using the XTerm file instead. Hmmm. Then I checked the location of the XTerm-color file. It is:
/usr/local/lib/X11/app-defaults/XTerm-color
Bingo.
I edited this XTerm-color file to enable dark background (so that I could see if the file had been sourced or not). Then I used the command
env 'XAPPLRESDIR=/usr/local/lib/X11/app-defaults/' xterm
and voila -- xterm with a dark background! So this is the way to source the XTerm-color file after setting your .Xdefaults file to use colour.
This is the high point of this enterprise. It goes downhill from here.
Overjoyed, I launched lynx. Surprise surprise -- lynx was in black&white (with a dark background of course, but still in b&w). I hurriedly edited XTerm-color to set dark blue and light green colours as fg & bg colours respectively, and restarted xterm and lynx. Now lynx was in blue&green, but only in 2 colours. The same was seen with vim. Then I checked the TERM setting.
-bash-3.00$ echo $TERM
xterm
What a shock! I am almost convinced that this is a bug in xterm. Even when it knows about the colour usage, it still sets TERM=xterm and not TERM=xterm-color. The less said about the TERMCAP entry the better. So its back to script kludging as before.
2. Even though setting XAPPLRESDIR solved the problem of sourcing the correct defaults file, this creates more problems than it solves. For one, by setting XAPPLRESDIR permanently to /usr/local/whatever/ (in .profile or such) all the resources in /usr/X11/lib/X11/app-defaults/ will now not be usable. There is no way to avoid this, unless you use the env crap every time. I am not sure even that would solve the problem (eg: what of programs you launch from such an xterm?).
3. X11 has a solution for file resource problems. It is to use the XFILESEARCHPATH variable instead and eschew XAPPLRESDIR completely. So I set
XFILESEARCHPATH=$XFILESEARCHPATH:/usr/local/lib/X11/app-defaults/%N%S
and launched xterm. However, this (and many other permutations) does not work.
The remaining may be of no interest to the general users, but I post it here anyway.
SFU documentation (the chm version) turns up a function
XtResolvePathname - search for a file using standard substitution
It appears that X applications use (or should use) this function to parse XFILESEARCHPATH. I ran a quick link /dump /symbols xterm (from cmd.exe of course: I have the free Microsoft Visual C++ Toolkit 2003), and sure enough, _XtResolvePathname turns up. So something is definitely calling this function from xterm. Then why is XFILESEARCHPATH not working ? I think its time to look into the source, but I haven't got enough time now...
< Message edited by jon493 -- Nov. 15, '05, 3:30:57 AM >
|
|
|
|
|
Limitations of the shell scipt 'solution' - Nov. 15, '05, 3:31:59 AM
|
|
|
jon493
Posts: 56
Joined: Oct. 14, '05,
Status: offline
|
If you put code like
if test "x$TERM" = "xxterm" ; then
TERM=xterm-color ;
fi
in your .profile, that would only affect your login shells. As proof, run another (regular) xterm from your login xterm. See? no colours! Thus you either have to invoke each xterm as xterm -ls, or put loginShell in your .Xdefaults (both making every xterm a login shell), or be stuck with b&w xterms for all but your login shell.
Even if you put the code in /etc/profile.lcl, making it 'global', it is only read for all users' login shells only, so you're stuck.
The 'solution':
For bash only. There can be similar solutions for other shells, but I am not proficient in using them, so if anyone has any ideas, please post them here.
Bash has an optional .bashrc file in your HOME directory. It is not created by default, but it is read by every bash launched on your system, login or otherwise. So if your default shell is bash (you may chsh to it if you want), create ~/.bashrc and add to it the following:
if test "x$TERM" = "xxterm" ; then
TERM=xterm-color ;
reset ;
clear ;
fi
From now on all xterms which use bash will support colour in lynx, vim etc.
|
|
|
|
|
Update: I found the solution - Nov. 16, '05, 7:22:35 AM
|
|
|
jon493
Posts: 56
Joined: Oct. 14, '05,
Status: offline
|
Just as things were getting interesting...
As MSDN's Dr. GUI (and probably countless others before him) said,
"Use the source, Luke!"
So I downloaded the latest XTerm(207) tarball, and started tinkering. (For information purposes, the xterm in the tool warehouse is XTerm(197) ).
I was right about some things, and wrong about others.
First, THANKS A LOT RODNEY! You got me thinking that this could be due to ncurses, and not a 'bug' in xterm. It turns out that part of the problem is due to ncurses, but the warehouse xterm does have problems.
Note: You must install ncurses 5.4 from the tool warehouse to proceed
1. The default installation of ncurses leaves the system termcap and terminfo untouched. This creates problems as xterm prefers to use termcap when it finds it. Step #1: Rename /usr/share/termcap to /usr/share/old.termcap, /usr/share/terminfo.src to /usr/share/old.terminfo.src, and /usr/share/terminfo/ to /usr/share/old.terminfo/. This gets rid of the confusion.
2. I checked out the script kludge solution with the script in profile.lcl instead of .profile. If your first shell is always a login shell (or xterm), it works! However, if you do fancy invocations like POSIX.EXE ing your way through without the -l switch, you are better off using the .bashrc solution.I will assume that your first shell is always a login shell. Keeping this in mind, Step #2: add the following line to your /etc/profile.lcl
export TERMINFO=/usr/local/share/terminfo
This will force programs to use the new terminfo database.
3. About setting the TERM value, xterm has a solution in the form of X resources. Simply add:
*termName: xterm-color
to your ~/.Xdefaults file and it should work (as the terminfo.src file from ncurses 5.4 says). This was the good news. Now the bad news...
4. No. 3 above fails miserably. It was back to the source, then (or at least to the INSTALL file). As it turns out, not only xterm source, but also the build is convoluted. It uses a hybrid of the configure system and the xmkmf system. The default build using xmkmf is crap. I will only talk about the ./configure build.The default configuration options are the cause of the problems we're facing. xterm is obsessed with termcap and will use it despite the presence of ncurses. Needless to say a proper TERMCAP description is neither provided nor required nor even recommended. TERMCAP is out to pasture. ncurses is forced with the option
--disable-full-tgetent
which uses the ncurses version of tgetent ().
5. While I was in a good mood, I added some more options (which are not necessary). I finally gave the following line:
$ ./configure --with-Xaw3d --enable-256-color --enable-88-color --enable-toolbar --with-terminal-type=xterm-256color --disable-full-tgetent
Note the --with-terminal-type option. This enables us to set a 'default' value of TERM, which will be checked against termcap/terminfo, used if found good, and defaulting to TERM=xterm if anything is wrong. This is the problem with the present xterm. It is probably linked with libtermcap, and searches for xterm-color in termcap on doing the .Xdefaults trick. Of course it fails and the default is set to TERM=xterm. If you do keep the old termcap file (and not rename it), this should work with the present xterm, although that would not be a proper solution.
6. This new xterm works like a charm. TERM is automagically set to xterm-256color, programs like lynx and vim immediately recognise it, and best of all, the TERMCAP entry is automatically set to a fallback xterm (without any actual termcap file present).
7. With these facts in consideration, I recommend a rebuild of xterm; and suitable modifications of the ncurses +INSTALL script (to supersede the old termcap/terminfo).
8. <WISH>
- 256 color xterm (it works)
- toolbar perhaps
- Xaw3d pleeeeease
- terminal-type to be set to xterm-256color by default. If anyone wants to use b&w (why?) he/she should be the one to use fancy flags like -tn or X resources.
- possibly using the install-ti option to install the nice terminfo/termcap files supplied in the tarball somewhere.
</WISH>
9. Last but not the least, I am always ready to help.
Thanks!
< Message edited by jon493 -- Nov. 16, '05, 7:24:41 AM >
|
|
|
|
 New Messages |
 No New Messages |
 Hot Topic w/ New Messages |
 Hot Topic w/o New Messages |
|
 Locked w/ New Messages |
 Locked w/o New Messages |
|
 Post New Thread
Reply to Message
Post New Poll
Submit Vote
Delete My Own Post
Delete My Own Thread
Rate Posts |
|
|
|
Printable Version
