Bash – How to Change $TERMINFO in bashrc Script

bashreadlineterminal

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".

Best Answer

So after digging around some more, I found what's going on. RHEL5's build of bash doesn't use terminfo at all (why, who knows, it's Red Hat), 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 that's 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.

Related Solutions

Bash readline: Key binding that executes an external command

Not all bash line editing is controlled from ~/.inputrc; much of it is configured via the bind builtin. In this case, you want something like

bind -x '"\C-gu":uptime'

in your ~/.bashrc.

Bash – sudo not executing bashrc as expected

sudo can be configured to set $HOME to match the new user when switching users, or not to. In your case, it appears it is set to not switch $HOME. That can be useful when you want to switch to user accounts that are dedicated to specific service applications, but still want to keep using your personal shell configuration and other settings.

And ~/.bashrc is actually just a shorthand for $HOME/.bashrc.

So when you do sudo -u newuser bash, sudo switches the username to newuser but $HOME is still set to /home/myuser.

When bash attempts to execute ~/.bashrc, it has a slight problem: as newuser, it might have no access to read /home/myuser/.bashrc unless you have specifically granted that access. If you haven't, that is probably why .bashrc is getting skipped. Because $HOME is still set to /home/myuser, there will be no attempt to execute /home/newuser/.bashrc.

If you want sudo to set HOME=/home/newuser, you can:

use the -H option with the sudo command: sudo -Hu newuser bash
or add Defaults>newuser always_set_home to your sudoers file to automatically set the home directory when switching to newuser only
or add Defaults:myuser always_set_home to sudoers file to automatically set the home directory to match the new identity when myuser is running any sudo commands
or add Defaults always_set_home to sudoers file to force this behavior for all sudo commands on the system. (Some Linux distributions have this enabled by default.)

If you don't especially want to switch the home directory when switching users, then you'll need to make sure the new user can read your personal shell startup files instead.

The minimal permissions you'd need to allow for sudo -u newuser bash to run /home/myuser/.bashrc are:

a search permission to /home/myuser
a read permission to /home/myuser/.bashrc

If there is no convenient user group that would be common to both myuser and newuser, and ACLs are not available (i.e. traditional Unix-style permissions only), this would be the traditional way to do it:

chmod 711 /home/myuser          # i.e. directory permissions drwx--x--x
chmod 644 /home/myuser/.bashrc  # i.e. file permissions      -rw-r--r--

If ACLs are available for the filesystem containing your home directory, you could do this instead to grant the minimal necessary access:

setfacl -m u:newuser:x /home/myuser
setfacl -m u:newuser:r /home/myuser/.bashrc

If the permissions of the home directory were initially drwx------, after this command the permissions to /home/myuser would look like drwx--x---+. To check the complete ACL, use getfacl:

$ getfacl /home/myuser
getfacl: Removing leading '/' from absolute path names
# file: home/myuser
# owner: myuser
# group: myuser
user::rwx
user:newuser:--x
group::---
mask::--x
other::---

Best Answer

Related Solutions

Bash readline: Key binding that executes an external command

Bash – sudo not executing bashrc as expected

Related Question