Linux TTY – Echoed Escape Sequences Not Interpreted

To get rid off the boot image: On other distros the idea is the same -> splash=no in boot kernel commandline or change the picture in /etc/bootsplash or equivalent.

On open suse 11.4 (and probably some earlier versions of suse) you can get rid of that background picture by using Yast on command line as follows:

System -> Boot Loader -> From boot images choose the one already marked -> Edit -> Optional kernel Command line parameters: change -> splash=no after that you have a professional black background as it should be.

To change this tty background picture to something nice:

Find this directory -> /etc/bootsplash/themes/opensuse/images and replace the file with your screen size to something you like. Don't change the file name! Just put something else there with that same name. In same size, of course :)

In most terminal emulators, long command lines […] are wrapped to a new line before the user submits the command by pressing Enter.

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 TIOCGWINSZ ioctl (falling back to the COLUMNS variable 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.