Why bother? Clearing scrollback buffer is handy in many ways, for example, when I wish to run some command with long output, and want to quickly scroll to start of this output. When scrollback buffer is cleared, I can just scroll to top, and will be done. Some considerations: There is clear command, according to man, > **clear** clears your screen if this is possible, including its scrollback buffer (if the extended "E3" capability is defined). In gnome-terminal clear does *not* clear scrollback buffer. (What is "E3" capability, though?) There is also reset, which clears, but it does a little bit more than that, and it is really slow (on my system it takes more than a second, which is significant delay for humans to be noticed). And there is echo -ne '\ec' or echo -ne '\033c', which does the job. And indeed it is much faster than reset. The question is, what is \ec sequence, how it differs from what clear and reset does, and why there is no separate command for it? There is also readline's C-l key sequence, which by default bound to clear-screen command (I mean, readline command, not shell command). What is this command? Which escape sequence it emits? How does it actually work? Does it run shell command? Or what? Again, in gnome-terminal, it seems like it works just by spiting out blank lines until prompt appear in top line of terminal. Not sure about other terminal emulators. This is very cumbersome behavior. It pollutes scrollback with chunks of emptiness, so you must scroll up more, and more. It is like a hack, rather than clean solution. Another question is, is there a readline command for mentioned \ec sequence? I want to bound it to C-l instead because I _always_ want to clear scrollback buffer when I clear the screen. And another question is how to _just type_ such escape sequence into terminal, to perform desired action? Then do not have to think about binding C-l to another readline command (if such command exists). I tried typing Esc, then c but this does not work. **UPDATE** This question answered mostly here: https://unix.stackexchange.com/a/375784/257159 . It is very good answer which explains almost all questions asked here.

Supose you present the following TUI in the shell: I need a set of libraries that can be used in the shell to do it. Being sure, ncurses has not been used, because it make a dependecy. Question: How to build the widget/window or another TUI in the shell?

When I connect to a remote macOS Sonoma from a Linux RHEL 8 with ssh -J user@portal user@mac and, once connected, I run vim somefile, I get some extraneous characters at the top-left of the "page" and also at the shell prompt after exiting Vim: ESC[>4;m **note:** Thanks to @LorinczyZsigmond tip of using script I managed to capture those bytes It's not the first time I'm experiencing this problem, with differents local/remote OS combinations (Solaris/FreeBSD/AIX/Linux/macOS), but previously I only had to install the terminfo packages on the remote NIXes to fix it. On macOS Sonoma though, the terminfo for the xterm-256color used by RHEL 8 is already in /usr/share/terminfo/78/xterm-256color, and changing TERM to xterm doesn't help. Any thoughts on what to do to fix the problem?

The thread's title pretty much says it all. When I googled this question, I found mentions of a program called untic that supposedly does what I want to do, but this program does not seem to be available in any of my distro's (Debian) official packages. Is there some other way to go from (compiled) terminfo to termcap?

I recently started to work in a shared Linux cluster that a version of gnu-screen that I consider unacceptably old (4.01, from 2006). I was not able to convince the system's administrators to install a more recent version of gnu-screen, so I installed my own off my home directory, using conda. Unfortunately, even after I installed my long-trusted ~/.screenrc file, my conda-installed instance of gnu-screen does not work well at all. For example, the backspace key does not erase the character to the left of the cursor; instead, it behaves like the space key, at least as far as what shows up on the screen. Hitting the C-r key, which I use *all the time* to search my history, disfigures my screen grotesquely. Other than gnu-screen's "command key" (which I have set to C-h), pretty much any chord involving Ctrl is messed up. Etc. I should emphasize that all these problems emerge only after I start a new gnu-screen session, using my conda-installed instance of gnu-screen. Outside of screen, or when I use the ancient /usr/bin/screen, my terminal behaves normally. Still, I suspect that the problem may have something to do with my TERM variable's setting at the time of invoking screen (namely TERM=xterm-256color), and/or the terminal emulator I am using (iTerm2 running on OS X), but I don't know how to go beyond these hunches. When I search online for solutions to this problem I come across massive amounts of trial-and-error. Is there a systematic, reasonable way to troubleshoot this problem?

I'm using a Wyse50 Terminal emulation on Rocky Linux 9. Man pages, help screens, etc., are unusable because the system outputs attribute and color codes that the terminal emulator doesn't understand; so, for example, man cp reads like this:

1mSYNOPSIS0mm
       1mcp 22m[4mOPTION24m]... [4m-T24m] 4mSOURCE24m 4mDEST0mm
       1mcp 22m[4mOPTION24m]... 4mSOURCE24m... 4mDIRECTORY0mm
       1mcp 22m[4mOPTION24m]... 4m-t24m 4mDIRECTORY24m 4mSOURCE24m...m  m

1mDESCRIPTION0mm

I've updated the latest terminfo packages and did an infocmp between the latest wy50 and the wy50 from a Linux 4 where everything worked fine. I see nothing in profile, bash_profile, bashrc or .bashrc that would set any color parameters. What am I missing? (other than a legacy application that belongs in the prior century)

I am trying to make my shell script supporting as much terminals as possible, that is, adding ANSI colors, bold and dim only when supported. However, I want to detect the number of colors supported. We can use tput colors. However, I find that some systems that are stripped down to minimal does not have it installed. So, I want to implement it in shell. How does tput colors work? Any equivalent of tput colors with POSIX commands? Please help and answer.

The output of tput ed is empty and I can't figure out why. Other capabilities work fine. Also ed is not missing from infocmp output so tput should match, right?

$ printf '%q' "$(tput ed)"
''

$ printf '%q' "$(tput home)"
$'\033'\[H

I'm using zsh on Mac OS 10.14.6 and iTerm2. TERM=xterm-256color.

Many modern terminal emulators include definitions for box drawing glyphs directly in their own source code, and disregard the versions provided by the font when rendering the display. Is there a general way for a program running in the terminal to detect which glyphs are rendered this way? Specifically, if a program makes use of additional box glyphs that might not be widely supported, what's the best way to check if they're available? Perhaps in terminfo? My current use case is a small personal-use project written in Python using ncurses for the graphical component, so bonus points for something that plays nicely with those, but I'm interested in all solutions. ---- EDIT: As an example, here's a set of characters provided by [kitty](https://sw.kovidgoyal.net/kitty/) ; a comment in the source code indicates they're intended for Powerline integration: If we try to render the same glyphs in Konsole, though, we get this: The glyphs displayed by Kitty are defined by the terminal itself, whereas the ones displayed by Konsole are provided by whatever font it's configured to use. Is there a general way for a program running in some arbitrary terminal to detect whether we'll see the something like the former vs. the latter?

I'm trying to write some code using the ncurses dialog library (available everywhere, source mirror is here ) and I'm trying to decide dynamically in code whether to use dialog or just print to stderr and prompt with getc() based on whether stdin/out/err are hooked up to char block devices, ttys, and what termcaps they have. I've stolen some code from less that seems pretty reliable at detecting whether it can render properly, and it looks for termcaps ce,cd,cl and either cm, or ho and ll, and either al or sr, otherwise it switches to dumb mode. But less has (much?) lower requirements than dialog, presumably (I just need yesno boxes, at least). I'm kind of surprised there's no check for caps in dialog or in ncurses, and no way to just ask if the terminal can handle things, or fail initscr if it doesn't have the caps? dialog on an emacs shell (not on ansi-term, it works fine there obvs) just spews nonsense text because it's a dumb terminal (same if you export TERM=dumb in a normal xterm), so there's clearly no capabilities checking going on here. I'm not a unix programmer most of the time, so is there some standard way of doing this that's robust? It's odd to me that this isn't a thing that's easy to check for. I can obviously grovel through the dialog yesno code and try to record all the ncurses stuff it calls, but that's a pain, so I'm hoping I'm just failing to find a clear terminal capabilities requirements list somewhere. **Update:** so I decided to mess around with making my own custom terminfo entry to test how minimal I could go and still get the yesno dialog, and it's pretty minimal, so the less tests are basically good. It was hard to figure out how to do this, so here's a brief summary for other folks from THE FUTURE: - Here are the termcap definitions you'll need to figure things out; you can work directly with terminfo definitions and skip a couple steps, but old software like less are using the termcap versions and so it'll be easier to just work in that space. - Assuming you've got an ncurses app that runs on your current terminal (or dialog --title Hi --yesno There 0 0), figure out what your TERM envvar is. I'm working in screen and emacs ansi-term, so they're screen and eterm-color in my tests, and of course dumb - Dump the one you want to muck with (that you're running the tests with because you want your new one to be a subset of a working one) using infocmp eterm > eterm2.info, this gives you the info version to work with. - Convert it to cap with infotocap eterm2.info > eterm2.cap - Look inside, and cut it way down, like here's my minimal cap file that will just barely run less without warnings:

#       hacked eterm for testing dialog
eterm2|gnu emacs term.el terminal emulation:\
        :am:mi:xn:\
        :co#80:li#24:\
        :ce=\E[K:cd=\E[J:cl=\E[H\E[J:\
        :ho=\E[H:\
        :cm=\E[%i%d;%dH:\
        :al=\E[L:

- Notice I changed the name at the beginning to eterm2 as well. - Convert that back to info with captoinfo eterm2.cap > eterm2.info - mkdir infodb to make the local dir where you're going to compile this test info. - export TERMINFO=$(pwd)/infodb to tell termcap/terminfo where to find it - tic -D should output that local dir first - tic -s eterm2.info will compile it to that dir - export TERM=eterm2 to set your new hacked terminal - Run your ncurses app or dialog --title Hi --yesno There 0 0 and it should show up in all its black and white simple glory. - You can play around with adding other commands back in to see what changes, but when you're done, rm -rf infodb, export TERMINFO=, and export TERM= and make sure things run right. **Update2:** Here is the code I ended up with which seems to work in all my tests:

if(TermMode == TERM_UNINITIALIZED) {
        struct stat s;
        if((isatty(STDOUT_FILENO) && (fstat(STDOUT_FILENO,&s) == 0) && S_ISCHR(s.st_mode)) &&
           (isatty( STDIN_FILENO) && (fstat( STDIN_FILENO,&s) == 0) && S_ISCHR(s.st_mode)))
        {
            // both stdout and stdin are char block device ttys, now check termcaps
            // mostly stolen from the gnu less source code, since it seems robust
            // https://github.com/gwsw/less/blob/22e4af5cccbfab633000c7d610f868a868ad6e1a/screen.c#L1280 
            char termbuf;
            char const* term = getenv("TERM");
            int const TGETENT_OK = 1;
            if(tgetent(termbuf,term) == TGETENT_OK) {
                char sbuf;
                char* sp = sbuf;
                char* sr = 0;
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wwrite-strings"
                // ce ce cl are required
                if((sr = tgetstr("ce",&sp)) && *sr &&   // eol clear
                   (sr = tgetstr("cd",&sp)) && *sr &&   // eos clear
                   (sr = tgetstr("cl",&sp)) && *sr)     // screen clear
                {
                    // cm or (ho and ll)
                    if(((sr = tgetstr("cm",&sp)) && *sr) ||   // cursor move
                       (((sr = tgetstr("ho",&sp)) && *sr) &&  // home
                        ((sr = tgetstr("ll",&sp)) && *sr)))   // lower left
                    {
                        // al or sr
                        if(((sr = tgetstr("al",&sp)) && *sr) || // add line
                           ((sr = tgetstr("sr",&sp)) && *sr))   // scroll reverse
                        {
                            // we've got what we need for ncurses dialog!
                            TermMode = TERM_DIALOG;
                            goto term_detected;
                        }
                    }
                }
#pragma GCC diagnostic pop
            }
            // we're at least connected to a tty
            TermMode = TERM_STDIO;
        } else {
            // no interaction, so gotta just abort
            TermMode = TERM_ABORT;
        }
term_detected:
        ;
    }

Anyway, it would still be very nice to know what the minimal termcaps are, but at the very least the ones listed above for less work, so I'm going to use those. Thanks, Chris

i just started using tmux and have been trying to bind my MENU key to prefix but it is giving me "bad key bind error", it would be nice to know what keys are valid or what to write in the conf file for keys to work

I'd like to get [Terminfo](https://en.wikipedia.org/wiki/Terminfo) for my terminal (rxvt-unicode) working, so that when I ssh from Linux to macOS, the Home/End and other keys work properly. Usually, to accomplish this with a Linux remote host, I use a script like the following: ssh "$1" 'mkdir -p ~/.terminfo/r' for f in /usr/share/terminfo/r/rxvt-unicode{,-256color} do scp "$f" "$1":.terminfo/r/ done However, this isn't working with macOS. When I run screen, first I was getting "TERM too long - sorry.". After updating it to the brew version (4.06.02), I'm now getting "Cannot find terminfo entry for 'rxvt-unicode-256color'." TERM is correctly set to rxvt-unicode-256color, and ~/.terminfo/r/rxvt-unicode-256color exists. Running screen with TERMINFO=$HOME/.terminfo/ also has no effect.

Some terminal applications (e.g. mosh) use the terminal in the alternate screen, thereby disabling the terminal emulator's local scrolling. mosh does not allow overriding its terminal settings (as far as I could find), so one simple way to force it to not use the alternate screen and (thus) keep local scrolling working is to tell it the terminal doesn't have an alternate screen: env TERM=dumb mosh mosh now no longer breaks scrolling, unfortunately TERM=dumb also doesn't have any other modern-ish terminal features, such as setting the application name in the titlebar. More useful is TERM=linux, but that still doesn't set the app name in the titlebar. **So, what is the most xterm-like $TERM setting that does not support an alternate screen?** notes:\ ‑ My default TERM value is xterm-256color.\ ‑ I realise there are other workarounds, like using tmux inside mosh, but sometimes I don't want to do that.\ ‑ I realize this only gives me the local scroll buffer, so this still misses output if the mosh session was disconnected and then reconnected itself. But sometimes that is good enough.

I have installed some custom terminfo with tic command. How do I list all terminfo in the database (e.g. with infocmp) and how to delete specific terminfo? Here's my idea as of right now: On Linux, system-wide terminfo database is located in /lib/terminfo (Debian), /usr/share/terminfo (Arch), and /usr/share/lib/terminfo (Solaris); On macOS, system-wide terminfo database is located in /usr/share/terminfo; User-defined terminfo database is in ~/.terminfo. For now I believe the terminfo database items could be altered by deleting the compiled items in those directories. So further questions are: Why are items terminfo organized in two hex digit directories (e.g. 31, 7a)? How are they organized? And if I write a new terminfo with tic into the database, but with an existent name, is the previous terminfo overwritten?

The effect of bold typeface (ANSI: CSI 1 m) seems to depend on the terminal emulator. For example, running the following script on different terminal emulators #!/bin/sh echo "TERM = $TERM" for mode in 0 2 1 '1;2'; do printf '\033[%s;38;5;%dm\033[48;5;%dm%s\033[0m\n' "$mode" 0 15 "testing ($mode)" done gives the following output Of the terminal emulators tested, only xterm properly renders bold text (mode=1). The other terminal emulators seem to select a brighter color for bold typeface (generally also combining this with a bold typeface). Oddly, st produces properly colored, bold text when given the parameters 1;2, corresponding to bold;faint. Thinking that perhaps these terminal emulators expect different control sequences for bold typeface, I checked terminfo, but found unanimity $ for term in xterm-256color st-256color rxvt-unicode-256color tmux-256color; do printf "%-24s" "$term"; TERM=$term tput bold | cat -v; echo; done xterm-256color ^[[1m st-256color ^[[1m rxvt-unicode-256color ^[[1m tmux-256color ^[[1m This leads to the question, what terminal-emulator parameters control the effect of bold typeface? How can the shift to brighter color be prevented? Can this be fixed through Xresources or terminfo customization? (As an aside, are there corresponding parameters for vim? It shows similar behavior, which does not necessarily correspond to that of the terminal emulator in which it is run.)

Suppose I have the following color support in one of my portable shell scripts:

-sh
#!/bin/sh

set -o nounset

tput_init_linux () { set_fg_color='tput setaf'; reset_color=$(tput sgr0 2>/dev/null); }
tput_init_bsd   () { set_fg_color='tput AF';    reset_color=$(tput me 2>/dev/null);   }
tput_init_none  () { set_fg_color=':';          reset_color=;                         }

if tput setaf 1 >/dev/null 2>&1; then tput_init_linux || tput_init_none;
elif tput AF 1  >/dev/null 2>&1; then tput_init_bsd   || tput_init_none;
else tput_init_none; fi

no_color () { printf '%s' "$reset_color"; }

colorize ()
{
    #tput bold
    case "$1" in
        (red)     $set_fg_color 1 ;;
        (green)   $set_fg_color 2 ;;
        (yellow)  $set_fg_color 3 ;;
        (blue)    $set_fg_color 4 ;;
        (magenta) $set_fg_color 5 ;;
        (cyan)    $set_fg_color 6 ;;
        (white)   $set_fg_color 7 ;;
        (*) printf '%s\n' "[ERROR] This color ('$1') is not supported by the colorize() function. Quiting!" >&2; exit 1 ;;
    esac
}

print_ok     () { colorize green;  printf '%s' '[OK] ';        no_color; }
print_notice () { colorize cyan;   printf '%s' '[NOTICE] ';    no_color; }
print_debug  () { colorize yellow; printf '%s' '[DEBUG] ' >&2; no_color; }
print_error  () { colorize red;    printf '%s' '[ERROR] ' >&2; no_color; }

One rather silly example of use follows:

-sh
grub_config_file=/boot/grub/grub.cfg
readonly grub_config_file

if [ ! -f "$grub_config_file" ]; then
    print_error; printf '%s\n' "GRUB config file not found at $grub_config_file. Aborting!" >&2
    exit 1
else
    print_ok; printf '%s\n' "GRUB config file was found at $grub_config_file. Searching for Windows..."
fi

*** Now, **my question is about the bold text**. Specifically, I am unsure if terminfo/termcap tput bold/tput md are portable or not, and if not what are the limitations of bold text? Thank you for your time.

I want to enable *italics* in tmux (inside iTerm2 on macOS Big Sur 11.3). I have achieved this by setting this in .tmux.conf

set -g default-terminal "tmux-256color"

And I have installed ncurses 6.2 using homebrew and set it first in the path. .zshrc:

export PATH="$HOMEBREW_PREFIX/opt/ncurses/bin:$PATH"

After those changes, italics work. However, now several ncurses-dependent programs fail to start: Both ncdu (1.15.1) and nano (2.0.6 ) error out with:

Error opening terminal: tmux-256color.

I get the impression that they don't support this TERM setting. Weirdly, ncdu 1.12 works with tmux-256color on my Raspbian computer. **What's wrong?** Aren't programs like ncdu and nano supposed to be compatible with tmux-256color? I have found a hacky workaround (for macOS, not needed on Raspbian). If I explicitly change back the TERM variable in .zshrc, everything (both italics and programs) works:

if [[ "$TERM" == "tmux-256color" ]]; then
  export TERM=screen-256color
fi

But my understanding is that setting TERM yourself is a big no-no. You are supposed to let the environment set that correctly. And I'm surprised it works at all - is tmux-256color compatible with screen-256color? Will this hack blow up in my face eventually?

How can one retrieve status of terminal settings like smam and rmam ? Reason is that I set rmam by: tput rmam in script, then proceed to set smam on exit: tput smam But if terminal has rmam set when script starts, I do not want to set smam on exit. --- How can this be done?

As the title asked, what's the difference? When should I use one or the other? Also, anyone got a "canonical" definition of putty-256color's termcap/terminfo? Google had been less than helpful for searching that. Heck, Google had been less than helpful for ALL my questions in this Question!

I've been looking into escape sequences lately, and I'm surprised of what they can do. You can even move an xterm X11 window with them (try printf '\e[3;0;0t'), wow! The most common way to know what features a terminal supports seems to be using a database. That's what ncurses does, and it's used by 99.9% of applications that rely on escape sequences. Ncurses reads the terminfo database for your shell's TERM environment variable in order to decide which features are supported by your console. You can change the TERM environment variable of your shell, and if you do it most applications could start using less features or misbehaving (try running nano or vim after setting TERM=""). I've seen that some escape codes cause the terminal to report stuff. For instance [6n causes the terminal to report the cursor position. (printf '\e[6n') - Why don't we use similar report mechanisms to let the console report which features it supports? Instead of coupling the features with the value of TERM, each console could advertise its own features, making the whole thing more precise and reliable. Why isn't this a thing? --- Edit: something that I should have asked before... I'd like to create a new escape sequence, to hack konsole and gnome-terminal in order to support it and to use it in some scripts. I'd like to be able to query the console in order to know whether the one I'm running supports this feature - what's the suggested way to do that?