TERM Tweaking for Fun and maybe not Profit

One may see advice to use some TERM environment setting or the other. This can be good or bad advice in that the custom TERM may fix or break something, or fix one thing and break another. Maybe the breakage (if any) may not be noticed because you do not miss some feature, or never hit some key.

Another method is to modify an existing or to create a custom terminal definition that has or lacks the features you want or do not want. This too has downsides: it takes time, the custom terminal definition may need to be present on all the systems you use, shared accounts may be complicated if two users disagree on the necessary terminal, vendors may improve their terminal defintions whose changes you now have to merge into yours, etc.

terminfo(5) is assumed, the older termcap(3) is ignored. First up, have a look at the current terminal definition. These on OpenBSD live under the /usr/share/terminfo directory, though one could have custom definitions in ~/.terminfo or other directories.

infocmp

So what we have here is a bunch of line noise, or attributes (colors, etc) and features (bold, clear, etc) and the corresponding character sequence to emit to cause the terminal to carry out the feature. xterm(1) and many other implementations use "Xterm Control Sequences", though other software (or hardware!) will vary. Your TERM will likely be different; tmux(1) may use a screen terminfo file, and some like the *-256color variants while I go out of my way to disable colors.

The definitions could be modified or created at the system level, though I've never done that as then you need to manage vendor updates, and potentially other users unhappy with a change to a standard definition. Instead, one can compile a terminal definition into a new directory; ~/.terminfo is common, though the TERMINFO and other environment variables can change this.

That's an expensive way to copy a definition; typically one would use this method to modify the blah file between the infocmp(1) and tic(1). This process will be necessary on any system that generates the wanted (or undesired) escape sequences; a modified terminfo database on your local system will be unknown to something you SSH to; the escape sequences are generated on the remote system, so will need to be corrected there. NFS or configuration management such as Ansible is typical to either have a shared home directory or means to automate configuration file changes across a large number of systems (where large for some is any number greater than zero). You could also simply rsync(1) your local ~/.terminfo directory up to that OpenBSD virt you have, and not customize any other systems you rarely deal with.

infocmp(1) has facilities for comparing definitions, or you could use diff(1) or similar. diff(1) might get pretty hard to read, though.

Color support has accidentally been removed, among other changes. Monotype monochrome, baby!

infocmp(1) also supports diff, which may be more cromulent than the above. Here we compare screen from the system directory with the one in my local directory.

If you do modify terminfo files, you'll probably want a script that makes them, and to periodically update your ~/.terminfo from the vendor definitions, as the vendor may on occasion make updates. One way to automate this would be to checksum the vendor s/screen file or whatever, and emit a notification when that checksum changes in the operating system. On notification, review what the vendor changed and if necessary update your definition to include the vendor changes. Probably I should write that script.

How to change what??

This can be learned by inspecting what programs emit and the relevant terminfo files. Is anything annoying that you might want to change? The program can be run under different TERM settings to see if what it emits changes, and also under different terminals (xterm, urxvt, or a real actual terminal you found somewhere) and terminal multiplexers (screen, tmux). The raw terminal output will be useful, in addition to any relevant visual changes between TERM definitions. The terminal output might be run through a hex viewer (hexdump(1), xxd, etc) or a custom tool could be used to markup common escape sequences and to hexify non-printable characters. script(1) or expect(1) may be useful if the terminal does not let you log the output stream somewhere else.

Not very easy to read? Maybe try a custom debugging tool, short for "terminal explainer" as based on "mansplain":

termsplain.l

And then you would run the tool under script(1) under a different or new TERM, and then compare the saved outputs for differences, etc. Process tracing and inspecting the source code may also be necessary to chase down how a program is generating what.

Example Changes

One might want inverse instead of something else (italics?) for the search highlight in less(1).

Assuming the terminal uses Xterm Control Sequences, then

This will need to be run for each TERM you use, e.g. xterm, screen, any of those with colors, etc, or you could have a loop in the script that iterates over all the definitions you want to modify.

A temporary file is not strictly necessary, but might be good to edit or review with diff(1) before passing the data to tic(1).

Renaming a Definition

This may be handy if you want to use the same directory tree for a modified terminal defintion. Simply modify the leading field which is the name (and alternate names) of the definition. Study the existing definitions to see how this works.

References

http://man.openbsd.org/man1/infocmp.1

http://man.openbsd.org/man1/tic.1

http://man.openbsd.org/man5/terminfo.5

Xterm Control Sequences

tags #infocmp #terminal #unix

P.S. terminfo changes may be necessary but not sufficient to prevent an application from doing the wrong thing; an application could simply ignore the terminfo database and emit color codes or whatever that the terminal will honor. In this case either the application will need to be changed to not do that, or the terminal changed to filter out the codes (e.g. xterm*colorMode:false in ~/.Xdefaults) or software written that wraps the application and filters out the bad codes before they reach the terminal.

For example, a terminfo ignoring program might simply be

assuming that Xterm Control Sequences are supported by the terminal. A program that honors the color definitions or whether colors are supported might use a library for this, curses for example:

hascolors.c

P.P.S. on some systems you may need something like

or at least I recall Mac OS X requiring that. YMMV. Oh and maybe to change "curses.h" to "ncurses.h" on the relevant include line in termsplain.l, the above code all assumes an OpenBSD shaped system.