Re: TERMINFO_DIRS

[Thomas Klausner <wiz%netbsd.org@localhost>]

On Sat, Oct 18, 2025 at 12:29:32PM +0100, RVP wrote:
> On Sat, 18 Oct 2025, Thomas Klausner wrote:
> 
> > Am I using TERMINFO_DIRS wrong or is it broken?
> > 
> >    export TERM=xterm-direct
> >    export TERMINFO_DIRS=/usr/share/misc
> >    zsh: can't find terminal definition for xterm-direct
> > 
> > i.e. zsh is fine with xterm-direct as TERM until I set TERMINFO_DIRS
> > to /usr/share/misc, which is the default directory of the terminfo
> > file.
> > 
> 
> TERMINFO_DIRS is misnamed. You have to supply a colon-separated list of
> *files* (w/o the .cdb extension).
> 
> TERMINFO_DIRS=/usr/share/misc/terminfo:/some/path/file1:/ano/ther/file2

Interesting, yes, that works:

export TERMINFO_DIRS=/usr/share/misc/terminfo

However, libterminfo seems to be in conflict with ncurses' variant
here, see e.g. https://linux.die.net/man/5/terminfo which describes
this as a list of directories:

    If TERMINFO is not set, the ncurses version of the terminfo reader
    code will instead look in the directory $HOME/.terminfo for a
    compiled description. If it fails to find one there, and the
    environment variable TERMINFO_DIRS is set, it will interpret the
    contents of that variable as a list of colon- separated
    directories to be searched (an empty entry is interpreted as a
    command to search /usr/share/terminfo). If no description is found
    in any of the TERMINFO_DIRS directories, the fetch fails.

The ncurses(3) man page included in ncurses-6.5 goes even further and
claims the variable is an ncurses extension:

   TERMINFO_DIRS
       This variable specifies a list of locations, akin to PATH, in which
       ncurses searches for the terminal type descriptions described by
       TERMINFO above.  The list items are separated by colons on Unix and
       semicolons on OS/2 EMX.  System V terminfo lacks a corresponding
       feature; TERMINFO_DIRS is an ncurses extension.

I don't know if the claim that TERMINFO_DIRS is an ncurses extension
is correct, but if it is, shouldn't NetBSD's implementation be more
compatible here?

Thanks,
 Thomas