On Jun 27, 3:52pm, Guillaume Maudoux (Layus) wrote:
}
} In my case, when TERMINFO_DIRS is set from /etc/zshenv, the new value is
} ignored by ncurses.
} The same applies to the subsequent TERM=$TERM in /etc/zshenv.
What does "the same" mean here?
} However, if I add a delay before TERM=$TERM, then the TERMINFO_DIRS
} update is seen, and the terminal is properly detected.
}
} Could it be that there are threads involved in zsh ?
There aren't threads, but there are signal handlers. We've had issues
before where certain terminal emulators will fire signals at the process
they are controlling at, shall we say, inopportune times.
However, the most common culprit would be the WINCH (window size change)
signal, which we block before reading init scripts and don't unblock
until ZLE is started up. And I don't know why ncurses would be doing
anything at all during /etc/zshenv, except via init_term() from those
assignments if ncurses is what provides tgetent().
Normally init_term() is called when setupvals() imports TERM from the
environment, which happens before zshenv is read. This would also be
the case for import of TERMINFO_DIRS, although if that happens before
TERM has been imported, init_term() will do nothing.
One thing I have noticed is that if TERMINFO_DIRS is in the environment
when the shell first starts up, tgetent() looks *only* there for $TERM.
Conversely if the shell starts and then TERMINFO_DIRS is assigned later,
the default definitions are also consulted. I don't know if that means
that TERMINFO_DIRS is ignored when a default has already been loaded.
This might differ in various tgetent() implementations.
Also, the "can't find terminal definition for ..." message is suppressed
during import from the environment.
If TERM is not in the environment
Aside: Does it matter that terminfodirssetfn() does not check (x == 0)
except before adding to the environment?