Ctrl D not exiting bash after sourcing bashrc

bashbashrc

The bashrc was not written by me, and sources a lot of different configuration files. Upon sourcing it, I can't exit bash with Ctrl+D anymore.

I found this related question about zsh, and I would like to know the mechanism used to do the same with bash.

When typing Ctrl+D in a login shell, I get:

Use "logout" to leave the shell.

When in a non-login shell,

Use "exit" to leave the shell.

As these messages are translated depending on the locale in use, this is probably not a system script. I would like to control both independently, if possible (disable this functionality for non-login shells, for instance). Is that possible?

Best Answer

Have a look at your configuration if a either bash variables or shell options are set:

Bash Variables

(Section 5.2 in the Bash Reference Manual)

IGNOREEOF

Controls the action of the shell on receipt of an EOF character as the sole input. If set, the value denotes the number of consecutive EOF characters that can be read as the first character on an input line before the shell will exit. If the variable exists but does not have a numeric value (or has no value) then the default is 10. If the variable does not exist, then EOF signifies the end of input to the shell. This is only in effect for interactive shells.

For example IGNOREEOF=2

Modifying Shell Behavior: The Set builtin

set allows you to change the values of shell options

(Section 4.3.1 in the Bash Reference Manual)

-o ignoreeof

An interactive shell will not exit upon reading EOF.

Getting to your question

I would like to control both independently, if possible (disable this functionality for non-login shells, for instance). Is that possible?

Yes. Scripts you source should check if the shell is a login shell and set the variable accordingly, something like this:

if shopt -q login_shell; then IGNOREEOF=10; else IGNOREEOF=0; fi

Note the value of 10 still allows you to leave the shell with Ctrl+D; you just need 11 consecutive strokes of it.

Related Solutions

Ubuntu – $ logout bash: logout: not login shell: use exit’

Your problem comes from piping binary files to stdout.

Patient: Doctor, it hurts when I do this.

Doctor: Don't do that.

Just use the reset command whenever you mess up the terminal settings.

Bash shell: how to reconcile portable configuration files and GUI terminal start-up types (login or interactive)

The most common problem caused by misuse of shell startup files is that if you define environment variables in .bashrc as opposed to .profile, they are not defined in applications that are not launched from a shell in a terminal but rather from a GUI menu.

Defining environment variables from .bashrc is generally not a good idea, but that's primarily because it's generally useless as the variables should already have been set at login time. It can cause a problem in practice if you (or an application) have deliberately changed the value of a variable (e.g. PATH) in a program and you launch a shell from that program and expect the setting to have remained the same.

You can avoid the problem of environment variables being reset by defining a “sentinel” value, and not defining anything if the sentinel value is set:

if [ -z "$JMLANE_PROFILE_READ" ]; then
  export ...
  export JMLANE_PROFILE_READ=1
fi

Another problem caused by terminals starting login shells is that there are things that should only be done once when you log in, for example starting a password agent (e.g. ssh-agent), or initiating a session (e.g. running startx in certain circumstances). The sentinel variable avoids these issues.

A shell inside a terminal is always interactive. As long as you source .bashrc from .bash_profile when the shell is interactive, you don't need to worry about the terminal starting a login shell.

An additional wart of bash's startup file handling is that .bashrc is read by non-interactive shells invoked by rshd or sshd. For example, when you do rsync somefile host.example.com:, if your login shell on host.example.com is bash, you can use .bashrc there to set the path to include rsync. You can tell you're in this situation because .bashrc is read from a non-interactive shell.

## .bashrc
if [[ $- != *i* ]]; then
  # either .bashrc was executed explicitly or this is a noninteractive rsh/ssh session
fi