Se você executar bash como:
LD_DEBUG=bindings bash
em um sistema GNU e grep para bash.*tinfo nessa saída, você verá algo como:
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'
Você pode confirmar a partir da saída de nm -D /bin/bash que bash está usando esses símbolos de tinfo.
Trazer a man page para qualquer um desses símbolos esclarece para que servem:
$ man tgetent
NAME
PC, UP, BC, ospeed, tgetent, tgetflag, tgetnum, tgetstr, tgoto, tputs -
direct curses interface to the terminfo capability database
Basicamente, bash , mais provavelmente seu editor readline (libreadline está estaticamente ligado), usa aqueles para consultar o banco de dados terminfo para descobrir sobre os recursos do terminal para que ele possa executar seu editor de linhas corretamente (enviando o escape correto seqüências e identificar teclas pressionadas corretamente) em qualquer terminal.
Quanto ao motivo pelo qual a linha de leitura está vinculada estaticamente em bash , você deve ter em mente que readline foi desenvolvido junto com bash pela mesma pessoa e está incluído na origem de bash .
É possível criar bash para ser vinculado ao libreadline instalado pelo sistema, mas somente se ele for de uma versão compatível e não for o padrão. Você precisa chamar o script configure no tempo de compilação com --with-installed-readline .