Categories
bash profile reload shell terminal

How to reload .bashrc settings without logging out and back in again?

2025

If I make changes to .bashrc, how do I reload it without logging out and back in?

0

    3233

    You can enter the long form command:

    source ~/.bashrc
    

    or you can use the shorter version of the command:

    . ~/.bashrc
    

    15

    • 108

      This is not exactly the same as logging in and back out. Say you had the following line in .bashrc: export PATH=$PATH:foo, and then you change it to export PATH=$PATH:bar. If you log in and back out, only bar will be in the PATH, but if you do what you suggest, both foo and bar will be in the PATH. Do you know of a way around this?

      Apr 25, 2013 at 1:09


    • 9

      @HighCommander4 – a very unsatisfactory way to sort of do what you want is to do “bash -l” however this actually creates a new subshell and when you logout you’ll return to the enclosing shell where “foo” is still in PATH. If you’re just interested in PATH, you could do “unset PATH” and reconstruct it from scratch, but probably easier/safer is to do “PATH=/bin:/usr/bin” before sourcing your .bashrc. How the PATH variable is built up on login is actually reasonably complex, involving input at the very least from login (see “man login”) and /etc/profile (see “man bash”).

      Sep 9, 2013 at 10:36

    • 2

      @Alex you can automate it by adding the line ~/.bashrc into ~/.bash_profile, though I don’t know if this is a good practice.

      Oct 24, 2013 at 8:55

    • 5

      I would also recommend creating an alias (which you could store in ~/.bashrc or ~/.bash_aliases) that opens .bashrc, and reloads it after the editor exits. You can do it by combining two commands in an alias, for example like so (if vim is your preferred editor, otherwise swap it out to something else): alias editbashrc='vim ~/.bashrc; source ~/.bashrc'. This will make the editing much smoother, since you don’t need to think about the reloading, after doing the edit, if using the custom alias.

      Nov 12, 2014 at 7:40


    • 12

      It will affect only the current terminal.

      Mar 16, 2015 at 23:26

    351

    Or you could use:

    exec bash
    

    This does the same thing, and is easier to remember (at least for me).

    The exec command completely replaces the shell process by running the specified command-line. In our example, it replaces whatever the current shell is with a fresh instance of bash (with the updated configuration files).

    17

    • 14

      Could you please explain the difference of source .bashrc command and exec bash?

      – muradin

      Nov 20, 2014 at 7:42

    • 24

      @muradin, source is a built-in shell command that executes the content of the file passed as argument, in the current shell. So in your example, it executes .bashrc file in the current shell. And exec command replaces the shell with a given program, in your example, it replaces your shell with bash (with the updated configuration files)

      – WhoSayIn

      Nov 24, 2014 at 13:15


    • 5

      In my hyper-specific circumstance, this totally rocked. My Dockerfile executes an install script that modifies .bashrc. I then need that to reload, but . ~/.bashrc will execute in dash rather than bash, so there is an error because shopt is missing. source isn’t found from the shell, so that solution is out as well. I tried this and the docker image built smoothly!

      – m59

      Jun 2, 2015 at 2:11

    • 14

      Elegant, but “does the same thing” is not entirely correct. source ~/.bashrc will preserve your entire shell environment (though likely modified by the sourcing of ~/.bashrc), whereas exec bash will only preserve your current shell’s environment variables (any ad-hoc changes to the current shell in terms of shell variables, function, options are lost). Depending on your needs, one or the other approach may be preferred.

      – mklement0

      Jan 28, 2016 at 22:49

    • 14

      @SEoF, when you say “bash inception” and if you are thinking what I think you are thinking, I must say that you are wrong. Unlike the movie, you don’t keep on going into bash from bash when you repeatedly do exec bash. The exec command replaces the shell with the program, in our case, bash. So, there is always one instance of bash in existence in the terminal.

      – John Red

      May 20, 2016 at 17:07

    161

    To complement and contrast the two most popular answers, . ~/.bashrc and exec bash:

    Both solutions effectively reload ~/.bashrc, but there are differences:

    • . ~/.bashrc or source ~/.bashrc will preserve your current shell session:

      • Except for the modifications that reloading ~/.bashrc into the current shell (sourcing) makes, the current shell process and its state are preserved, which includes environment variables, shell variables, shell options, shell functions, and command history.
    • exec bash, or, more robustly, exec "$BASH"[1],
      will replace your current shell with a new instance, and therefore only preserve your current shell’s environment variables (including ones you’ve defined ad hoc, in-session).

      • In other words: Any ad-hoc changes to the current shell in terms of shell variables, shell functions, shell options, command history are lost.

    Depending on your needs, one or the other approach may be preferred.


    Note: The above applies analogously to other shells too:

    • To apply the exec approach to whatever your default shell is, use exec $SHELL
    • Similarly, the sourcing approach requires you to know and specify the name of the shell-specific initialization file; e.g., for zsh: . ~/.zshrc

    [1] exec bash could in theory execute a different bash executable than the one that started the current shell, if it happens to exist in a directory listed earlier in the $PATH. Since special variable $BASH always contains the full path of the executable that started the current shell, exec "$BASH" is guaranteed to use the same executable.
    A note re "..." around $BASH: double-quoting ensures that the variable value is used as-is, without interpretation by Bash; if the value has no embedded spaces or other shell metacharacters (which is likely in this case), you don’t strictly need double quotes, but using them is a good habit to form.

    7

    • You answered my question before I could ask it. This is good to know; I often set my CLASSPATH for a single session.

      – swinefish

      Apr 7, 2016 at 8:22

    • So even if I call exec “$BASH” will the variables that .bashrc sets be found in the shell I open next (using the same executable as my current session) ?

      – nitinr708

      Aug 1, 2017 at 8:49

    • 3

      @nitinr708: Yes, exec $BASH will source ~/.bashrc, so you’ll see its changes to the shell environment in the new session.

      – mklement0

      Aug 1, 2017 at 12:45

    • This is why I use broadcast all + source. Best of both worlds, imo.

      – Nate T

      Oct 2, 2021 at 5:43

    • @i_want_more_edits: $SHELL reflects whatever shell is the current user’s default shell, which may or may not be Bash.

      – mklement0

      Jan 6 at 2:19