I happen to enjoy the ability to change the appearance of my eq, but I guess to each his own right? I like being able to wear a fish on my head if I want, I don't play these games for their realism, I play because the real world sucks ass and I want to get away from it for a while. Or at least I used to play for these reasons. Now I create, which is far more enjoyable. It's a good thing there's a bunch of people who like things different ways, that means there's more variety in the games.

Just for amusement, I've been toying with the xterm256 colour codes a bit. I cobbled up a little perl thing to convert RGB values (24-bit ones) into the closest xterm or ANSI (16-colour) match, along with printing the closest "named colour" from the X11 rgb.txt file.

I'm toying with the idea of allowing the in-game colour codes to use full 24-bit values by either hex notation or name (such as SteelBlue).

Here's a screenshot of the output. You may recognize the colour cube, as that top part is borrowed from the folks at the gvim site, who in turn borrowed it from the folks at x11.org. :)



EDIT: Oh, it should be noted that if you output xterm256 codes to a standard ANSI, Linux, or vt100 terminal, really bad things happen. :) My old terminal emulator doesn't support these, and in Linux/vt100 mode, it gets flashing text and interesting lines. In ANSI mode, it even messed up the font so I got some unreadable extended character set. Be careful out there!

Looks like we use different methods to determine the closest color match. My method is far from ideal, but it was the best 1 line algorithm I could think of. Here's the output from the public domain snippet I released, left side is xterm 256, right is ANSI, bottom is the grayscale.

Of probably interest only to myself and to Scandum… :)

Putty appears to define the "standard" ANSI colours using the values 0x00, 0x55, 0xBB, and 0xFF – in the combinations you'd expect. Since my code uses distance to find the closest colour match, that should change my output a fair amount.

Also of interest to myself…. changing from a terminal type of "Linux" to a terminal type of "xterm-256color" seems to have made the colour output of LS stop showing compressed files as bright red? Weird. As long as nethack still works, I'll be OK.

This is quite expected actually; the "environment" (whatever that may be in your case) looks at the terminal type and makes all kinds of decisions as a consequence of that, not the least of which is changing color output.

It was unexpected, because it still applies the OTHER colours, such as directories and executables. It seems strange that it would only lose one of the highlighting attributes.

Sounds like a typo in a configuration file to me. I guess you could file a bug report, if you know where it's supposed to go.

I'm using putty and ls only highlights .exes and directories and my startup script for me as well. In cygwin ls highlights nothing. I've never seen this before, not even in putty of 5 years ago. I just thought this was a new feature of putty.

Yeah, it's got to be a termcap/terminfo issue. If I do an "export TERM=linux" and then rerun by .bash_profile, it highlights compressed files in red, directories in blue, executables (or those with the execute bit set) in green. If I let it remain xterm or xterm-256color, it still does the directories and executables, but I lose the compressed file highlighting.

Very weird.

I'm still not sure why this is "weird" – it just means that whoever did the config file for xterm didn't want compressed files highlighted in red. Unless you just mean that it's weird that not all config files are exactly the same? I'm not sure if the config files are meant to represent the exact same thing across terminals, or some kind of historic configuration. :shrug:

I'm not using an actual xterm, I'm using Putty which is a terminal emulator. That rules out all X11 related configuration, since there is no X server involved (No, I don't run one… it's a server, I ssh in). It's not an issue with Putty itself, since I can change the TERM variable and get different behaviors without making any changes to the terminal itself. That means it's an interaction between the GNU ls colour code and the termcap/terminfo library. That is a whole different class of issue than an application config file. As it happens, my LS_COLOR variable is empty as well, meaning this is what happens with the default configuration.

It not being red isn't the issue. It not being consistent is. If I use the colour options of /bin/ls, and it highlights various types of inodes with various colours, how can it NOT be "weird" to move to a terminal which fully supports ALL the colour combinations I had before, and then some, and have it LOSE highlighting with no changes on my part?

It's not like the ANSI codes for red went away…

Had it been the other way around, dropping from a 256 colour xterm to a 16 colour display, I would have thought nothing of losing some of the highlighting, since the terminal might have simply not supported what was used before. Had I lost ALL colour support, I also wouldn't have though it odd – since maybe the dircolors system doesn't have any entries for xterm or xterm-256color terminals… yet it does, and THAT is why it's weird. Why lose SOME entries but not others?

I thought we've been talking about the terminal configuration file on the server all along now, sorry if I didn't make that clear earlier. When I said:

"the "environment" (whatever that may be in your case) looks at the terminal type and makes all kinds of decisions as a consequence of that, not the least of which is changing color output."

I was talking about applications on the server, not putty. If the server sets up terminfos differently, which is to be expected, it is also to be expected that some things are not identical. Recall that the server applications have no idea what kind of terminal you're actually running beyond the $TERM variable you give it.

So you're saying that the termcap/terminfo system would (in any sane world) intentionally be configured so that a terminal class (xterm) which is a superset of another terminal class (ansi or linux) would lose functionality?

If you're saying that each application (such as GNU ls) has to be custom configured for each terminal type…. doesn't that violate the entire reason terminfo was created?

I certainly can't argue with that, since it appears that one of those is the case… I do, however, call that weird. *shrug*

I would have assume that /bin/ls would have said "My config says highlight compressed things in red, hey terminfo, I need the code for red in whatever you are", and terminfo should certainly be able to reply with the right ones for an xterm, as easily as it did for an ansi terminal.

I know Putty is handling them correctly, because if I use "echo" to emit the several possible sequences for red, it works fine.

Oh well, I'll put it down to another example of one part of linux working one way, and another part working some other way, and someday I'll stumble upon the right voodoo combination of config files to fix it. :)

I have no idea what policy they use to set up the configuration files. I don't know if they do it to keep some kind of historic compatibility, or if somebody just forgot to do this, or if the author doesn't like the highlighting…


For starters I'm not sure how the applications interact with the library, but even assuming that you are correct, I'm not sure how it violates the point of the library, which is to expose terminal capability information that the application then does what it wants with.


Well, this is certainly an assumption. ls uses the environment variable LS_COLORS to determine colors, and if that's not set, it uses some default. That default very well might come from the terminal configuration files, in which case this whole thing is "explained", although now we still have to decide if it's a feature or a bug… :wink:


I suspect that this has nothing whatsoever to do with the client terminal, and everything to do with the server configuration files and/or applications and/or libraries.

The point of the library is so that application developers don't need to know how to print text in red for the hundreds of different makes and models of terminals out there. Thus, you ask "do I support colour"? If yes, "tell me about red" should return the correct terminal codes to make things red. Since some applications (like nethack) seem perfectly able to make things red on both xterm and ansi terminals, I don't understand why ls would fail to do so.



If ls is keeping different configuration settings for various terminals, it's bypassing the point of using termcap in the first place. Again, if I suddenly had NO colour, I'd just assume it didn't think xterm could do colour and fell back to standard mode. The fact that it does DIFFERENT highlighting colours is what's weird.

It doesn't help that the GNU people are man page biggots who won't put full documentation in the tried-and-true standard troff format, but insist on making people try to use their pathetic "info" format….

At this point I think the best thing to do, if this really is an issue for you, is to figure out what exactly is going on regarding the interaction between ls, terminfo, termcap, etc. We don't know if ls is the one keeping separate configuration files, we don't know if the library operates by saying "give me the color red", etc.

Heh, it's an issue in much the same way it would be an issue if I got a new television and it refused to display the Home Shopping Network. I don't particularly care about HSN, but it would bug me to no end to have a new TV that refuses to show a channel my old TV showed just fine.

Have you established that nothing at all shows the kind of red you're looking for when you log in using that termtype? I'm still not convinced that this is a "bug", and might have been a configuration decision (and were it a bug, it could be from one of several components).

Just to tendorize the dead horse so it makes better glue….

Here are a pair of screenshots showing my investigation into a mismatch between the ANSI sequence values (as seen in Putty) and the xterm sequence values (also as seen in Putty).

vs.

The first one assumes the RGB values for the plain ANSI values and the extended xterm values use the same 6 points from 0 to 255…. namely, 0x00,0x55,0x88,0xBB,0xDD,0xFF.

The second sets the RGB values for the plain ANSI codes to be 0x00,0x55,0x88,0xBB,0xDD,0xFF, but uses the xterm documentation values for the xterm extended values of 0x00,0x5F,0x87,0xAF,0xD7,0xFF.

This appears to be correct, since if you examine the solid backgrounds of the text at the bottom, you'll see the yellows and reds are not quite the same.

Obviously, the actual colors show will be what they will be, regardless of anything else… but it does affect what the "nearest match" code selects, as you can see. Does anyone care? Probably not.

Which one looks better? Hmmm, you decide. :)

Keep in mind there are also bold background colors using: \eKeep in mind there are also bold background colors using: \e[100m to \e[107m