Originally you had just dumb terminals - at first actually teletypewriters (similar to an electric typewriter, but with a roll of paper) (hence /dev/tty - TeleTYpers), but later screen+keyboard-combos - which just sent a key-code to the computer and the computer sent back a command that wrote the letter on the terminal (i.e. the terminal was without local echo, the computer had to order the terminal to write what the user typed on the terminal) - this is one of the reason why so many important Unix-commands are so short. Most terminals were connected by serial-lines, but (at least) one was directly connected to the computer (often the same room) - this was the console. Only a select few users were trusted to work on "the console" (this was often the only "terminal" available in single-user mode).
Later there also were some graphical terminals (so-called "xterminals", not to be confused with the xterm-program) with screen & graphical screen-card, keyboard, mouse and a simple processor; which could just run an X-server. They did not do any computations themselves, so the X-clients ran on the computer they were connected to. Some had hard disks, but they could also boot over the network. They were popular in the early 1990s, before PCs became so cheap and powerful.
Later still, there were "smart" or "intelligent" terminals. Smart terminals have the ability to process user input (line-editing at the shell prompt like inserting characters, removing words with Ctrl-W, removing letters with Ctrl-H or Backspace) without help from the computer. The earlier dumb terminals, on the other hand, could not perform such onsite line-editing. On a dumb terminal, when the user presses a key, the terminal sends/delegates the resulting key-code to the computer to handle. After handling it, the computer sends the result back to the dumb terminal to display (e.g. pressing Ctrl-W would send a key-code to the computer, the computer would interpret that to mean "delete the last word", so the computer would handle that text change, then simply give the dumb terminal the output it should display).
A "terminal emulator" – the "terminal-window" you open with programs such as xterm or konsole – tries to mimic the functionality of such smarter terminals. Also programs such as PuTTY (Windows) emulate these smart terminal emulators.
With the PC, where "the console" (keyboard+screen) and "the computer" is more of a single unit, you got "virtual terminals" (on Linux, keys Alt+F1 through Alt+F6) instead, but these too mimic old-style terminals. Of course, with Unix/Linux becoming more of a desktop operating system often used by a single user, you now do most of your work "at the console", where users before used terminals connected by serial-lines.
It's of course the shell that starts programs. And it uses the fork system-call (C language) to make a copy of itself with a environment-settings, then the exec system-call is used to turn this copy into the command you wanted to run. The shell suspends (unless the command is run in the background) until the command completes. As the command inherits the settings for stdin, stdout and stderr from the shell, the command will write to the terminal's screen and receive input from the terminal's keyboard.
There are eight standard ANSI colors, supported by every terminal emulator. Most terminal emulators also have eight bright variants of the standard ANSI colors.
However, the actual color values that the escape codes map to aren't standardized, and in fact they often slightly vary among terminal emulators. So if you do printf "\e[31;47mTest\n" to print red text on a white background, the actual hues of red and white you get may be different depending on the terminal emulator you use.
So that partly explains the problem: color values aren't standard, and LXTerminal may have different defaults for its color palette that you're not used to. If you look around in the settings, usually you can configure the color scheme to be whatever you like.
The other problem you face is that what the bold attribute actually does isn't standardized either. There are three possibilities: it can make the font bold, it can make the foreground color brighter, or it can both make the foreground color brighter and make the font bold.
Again, the default behavior here varies among terminal emulators, and you can usually change it if can you find the right setting. Grep for something mentioning 'bold' or 'bright'.
If you want to use a bright color, then you can use the so-called aixterm color escape codes instead of bold. These aren't standard, but they're supported in every modern terminal emulator I know of. Unlike bold, they always use bright colors, plus they can be used to display bright background colors.
So for example, if you wanted to print bright red text on a bright white background, you would do this: printf "\e[91;107mTest\n".
For reference, here's a table of all the color escape codes:
| ANSI | ANSI | ANSI | | Aixterm | Aixterm
| Color | FG Code | BG Code | Bright Color | FG Code | BG Code
+---------+---------+-------- +----------------+---------+--------
| Black | 30 | 40 | Bright Black | 90 | 100
| Red | 31 | 41 | Bright Red | 91 | 101
| Green | 32 | 42 | Bright Green | 92 | 102
| Yellow | 33 | 43 | Bright Yellow | 93 | 103
| Blue | 34 | 44 | Bright Blue | 94 | 104
| Magenta | 35 | 45 | Bright Magenta | 95 | 105
| Cyan | 36 | 46 | Bright Cyan | 96 | 106
| White | 37 | 47 | Bright White | 97 | 107
Best Answer
This is not a function of the terminal emulator.
It is a function of your shell. Your shell is not a full-screen application, but it is doing cursor addressing.
When you are editing a command line in a shell, the line editing library in the shell is in full charge of how the line being edited is displayed. In the Bourne Again shell this is the GNU readline library. The Almquist shell uses libedit. Other shells, such as the Z Shell, have their own libraries.
These libraries are layered on top of the termcap/terminfo libraries, which record the terminal capabilities of your terminal emulator. Those capabilities include amongst other things the control sequences for positioning the cursor in relative or absolute terms, the sequences for clearing to the end of the line and the end of the screen, and whether or not your terminal has automatic margins.
With this and information about the width of the terminal determined from the
TIOCGWINSZioctl(falling back to theCOLUMNSvariable for some libraries, or the termcap/terminfo database for others) in hand, the line editing library in the shell tracks the command line length and how many terminal lines it is displayed across. It intelligently moves the cursor around to repaint the input line as it is edited. Sometimes it might rely upon automatic margins, if your terminal has them. Sometimes it may explicitly reposition the cursor using control sequences.The fact that it is doing this is what causes effects such as those discussed at https://superuser.com/questions/695338/ . One can mess up its idea of where the cursor is, and what cursor motions it needs to emit to write to a particular place on the screen, with incorrectly delimited control sequences in a prompt string.
Your terminal emulator does not deal in the notions of command lines, or line editing. It is not part of those layers. It sees a simple stream of characters and control sequences, which it must render. It is your terminal emulator's responsibility to implement the control sequences that are advertised for it in its termcap/terminfo entry. GNU readline, libedit, ZLE,
vim,screen, and others will use what they find advertised. If you state in termcap/terminfo that your terminal has automatic margins, for example, then the emulator must do a line wrap when a character is printed at the right margin. If you state that your terminal can move the cursor up and down, then it must indeed do that when it receives the appropriate control sequences.By the way: If GNU readline finds that it cannot move the cursor up, because the termcap/terminfo entry does not state a way to do so, one doesn't actually see line wrap at all. readline falls back to a mode where it sideways scrolls the input line, all on one line.