Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm trying to set TERMINFO="$HOME/.terminfo" within my .bashrc script. The reason being is that my terminal isn't in the system terminfo location, and so I have its terminfo file in my home directory.
The problem here is that the change doesn't take effect for the current shell, only subshells. I'm guessing it's because readline is being initialized before bash reads the .bashrc file.

So is there any way to solve this issue? Perhaps some way to re-initialize readline so the changed $TERMINFO takes effect?
I'm trying to avoid doing an exec bash after setting it, as then I have to make sure I don't end up in a re-exec loop, and that's just ugly (though doing exec bash after setting it does work).

EDIT: This is not a issue running the script. I know for a fact the .bashrc script is being run and that $TERMINFO is being set. Running echo $TERMINFO after the shell has finished starting shows the correct value.

EDIT2: It appears this might be bash or readline library version related. I can't duplicate the issue with bash-4.2.20 and readline-6.2_p1, but I can with bash-3.2 and readline-5.1.3.

"No" is an acceptable answer if it's not possible. But it would be nice to know what's going on that causes the answer to be "no".

share|improve this question
can you post an answer as to what the newest version you've found this affects, then we'll close – xenoterracide Apr 11 '12 at 5:57
@xenoterracide No, this question should not be closed! Even if it doesn't apply to the latest version of all involved software, it's still useful for people running older versions. There's no reason to block answers or delete the question. – Gilles Apr 11 '12 at 7:21
@gilles going on the suggestion of another mod, but I'm really kind of indifferent. – xenoterracide Apr 11 '12 at 7:24
From what I see in the bash source, the terminal handling code is reinitialized (sv_terminal in variables.c) when TERMINFO changes at least since 2.05. I haven't looked at readline or tested. – Gilles Apr 11 '12 at 22:06

From man bash - the invocation section:

When bash is invoked as an interactive login shell, or as a non-interactive shell with the --login option, it first reads and executes commands from the file /etc/profile, if that file exists. After reading that file, it looks for ~/.bash_profile, ~/.bash_login, and ~/.profile, in that order, and reads and executes commands from the first one that exists and is readable.

To set up your environment, include the terminfo line (and any other environmental variables you would like to set) in either .bash_profile or .profile.

See this Superuser answer for more detail.

share|improve this answer
Already tried that, doesnt work. In fact my .bash_profile sources my .bashrc. I'm dead certain its being set because echo $TERMINFO shows it. – Patrick Apr 11 '12 at 2:58

bash only reads .bashrc when it starts.

So you need to do source ~/.bashrc to re-load it in the current session.

share|improve this answer
up vote 3 down vote accepted

So after digging around some more, I found whats going on. RHEL5's build of bash doesnt use terminfo at all (why, who knows, its redhat), it uses termcap. However there is apparently another bash on the box which does use terminfo. This is why subshells and re-execing would work, as they would use the other bash, not the default one. I feel stupid for not noticing this.

This can be determined from comparing 2 commands:

# ldd "$BASH"
    linux-vdso.so.1 =>  (0x00007fff4f1fd000)
    libtermcap.so.2 => /lib64/libtermcap.so.2 (0x0000003e0bc00000)
    libdl.so.2 => /lib64/libdl.so.2 (0x0000003e07000000)
    libc.so.6 => /lib64/libc.so.6 (0x0000003e06c00000)
    /lib64/ld-linux-x86-64.so.2 (0x0000003e06800000)

# ldd `which bash`
    linux-vdso.so.1 =>  (0x00007fff643fd000)
    libncurses.so.5 => /usr/lib64/libncurses.so.5 (0x0000003e0d800000)
    libdl.so.2 => /lib64/libdl.so.2 (0x0000003e07000000)
    libc.so.6 => /lib64/libc.so.6 (0x0000003e06c00000)
    /lib64/ld-linux-x86-64.so.2 (0x0000003e06800000)

Noticing that one is linked against libtermcap, and the other against libncurses.

I should have specified that I was using RHEL here, as thats apparently the critical factor. Why they use termcap when pretty much everyone else in the world has abandoned it makes no sense, but there it is.

share|improve this answer
Does the rpm changelog or spec file give any clues why they chose term cap? – Mikel Apr 13 '12 at 16:43
According to the bash configure file termcap is the default. And the Fedora spec file shows they don't pass --with-curses. – Mikel Apr 13 '12 at 16:58

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.