Si vous vous exécutez en bash
tant que:
LD_DEBUG=bindings bash
sur un système GNU, et grep pour bash.*tinfo
dans cette sortie, vous verrez quelque chose comme:
797: binding file bash [0] to /lib/x86_64-linux-gnu/libtinfo.so.5 [0]: normal symbol `UP'
797: binding file bash [0] to /lib/x86_64-linux-gnu/libtinfo.so.5 [0]: normal symbol `PC'
797: binding file bash [0] to /lib/x86_64-linux-gnu/libtinfo.so.5 [0]: normal symbol `BC'
797: binding file bash [0] to /lib/x86_64-linux-gnu/libtinfo.so.5 [0]: normal symbol `tgetent'
797: binding file bash [0] to /lib/x86_64-linux-gnu/libtinfo.so.5 [0]: normal symbol `tgetstr'
797: binding file bash [0] to /lib/x86_64-linux-gnu/libtinfo.so.5 [0]: normal symbol `tgetflag'
Vous pouvez confirmer à partir de la sortie de nm -D /bin/bash
cela en bash
utilisant ces symboles de tinfo.
Apporter la page de manuel pour l'un de ces symboles précise à quoi ils servent:
$ man tgetent
NAME
PC, UP, BC, ospeed, tgetent, tgetflag, tgetnum, tgetstr, tgoto, tputs -
direct curses interface to the terminfo capability database
Fondamentalement, bash
plus vraisemblablement son readline
éditeur (libreadline est lié statiquement dans), utilise ceux-ci pour interroger la base de données terminfo pour en savoir plus sur les capacités du terminal afin qu'il puisse exécuter correctement son éditeur de ligne (en envoyant les séquences d'échappement appropriées et en identifiant correctement les pressions de touches) sur n'importe quel Terminal.
Quant à savoir pourquoi readline est lié statiquement bash
, vous devez garder à l'esprit qu'il readline
est développé aux côtés bash
de la même personne et est inclus dans la source de bash
.
Il est possible de construire bash
pour être lié au système installé libreadline
, mais seulement si celui-ci est d'une version compatible, et ce n'est pas la valeur par défaut. Vous devez appeler le configure
script au moment de la compilation avec --with-installed-readline
.
TERM
? Ah, tant pis - je vois que le paquet source estncurses
.