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

Question

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

score 2958 · Accepted Answer · edited Oct 21 '20 at 14:18

2958

You can enter the long form command:

source ~/.bashrc

or you can use the shorter version of the command:

. ~/.bashrc

edited Oct 21 '20 at 14:18

Harry B

2,511
1
17
40

answered Mar 25 '10 at 18:01

George Hawkins

31,923
5
27
40

i seem to keep having to do this every time i open terminal... is there a way to automate it? – Alex Apr 07 '12 at 14:39
97

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? – HighCommander4 Apr 25 '13 at 01:09
what is that "command"? I did "man command", but it has no info about it. Searching gives no info either http://www.yandex.com/yandsearch?text=linux+man+source&lr=87 . Is it a command at all? – Tebe Sep 06 '13 at 19:46
1

@gekannt - if you do "type source" you'll see that source isn't a normal command but rather a "shell builtin" - this means you won't find an executable for it somewhere in the file system, e.g. in /usr/bin, instead it is implemented as part of the shell. So if you do "man bash" and search for the section "SHELL BUILTIN COMMANDS" and then search for "source" you'll find a good explanation of what source does (and if you understand fork as well then it should become clear why source is a builtin rather than a command). – George Hawkins Sep 09 '13 at 10:16
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"). – George Hawkins Sep 09 '13 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. – Vivek Gani Oct 24 '13 at 08: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. – Samuel Lampa Nov 12 '14 at 07:40
9

It will affect **only** the current terminal. – matepal297 Mar 16 '15 at 23:26
I'm using this alias to edit bashrc for all users: ***alias bashrc="sudo nano /etc/bash.bashrc; source /etc/bash.bashrc"*** – Tarik Aug 20 '17 at 14:43
1

I think the answer below from @WhoSayIn should be preferred over this to prevent the PATH problem discussed above: `exec bash` – zenw0lf Dec 23 '17 at 23:28
Seems `source ~/.bashrc` this throw out of current python virtualenv. – mrgloom Jul 01 '19 at 18:22
This will only be valid for current terminal, whether using "fresh start" exec bash, or "ad-hoc" source ~/.bashrc. I am currently working from home, I want to be able to SSH in to my remote host and have all updated settings without executing these commands each time I make a new SSH connection. I cannot access office to perform on-site log out/restart, due to practical and bureaucratic reasons. Any suggestions? – MahNas92 Jul 06 '20 at 16:44

score 320 · Answer 2 · edited Dec 17 '19 at 22:10

320

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

edited Dec 17 '19 at 22:10

Jonathan Gilbert

3,223
17
24

answered Mar 06 '12 at 13:11

WhoSayIn

3,821
2
17
19

14

Could you please explain the difference of `source .bashrc` command and `exec bash`? – muradin Nov 20 '14 at 07:42
21

@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 '14 at 13:15
2

It's great especially because the bashrc may be updated either in `/etc` or `/home` directory, and we don't need to care about this. – Han Mar 31 '15 at 10:07
4

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 02 '15 at 02:11
1

For CentOS7 and with helper bash configs, this was most helpful. Doing `. ~/.bashrc` did not reload my custom aliases file. – onebree Oct 07 '15 at 15:53
12

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 '16 at 22:49
1

@mklement0, thanks for the detailed information. This solution would work in many cases but I guess you may need to use -source- in situations like you mentioned. – WhoSayIn Feb 01 '16 at 12:31
12

@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 '16 at 17:07
1

Some specific examples of the kind of surprise [@mklement0 mentioned](https://stackoverflow.com/questions/2518127/2518150#comment57870320_9584378): Your `pushd` / `popd` directory stack will be erased (except for the CWD), and your `PS1` prompt will be reset. Some dev environments, like Python's `virtualenv` / `venv`, alter your `PATH` and other variables, and put the name of the active environment in your `PS1` prompt. After `exec bash`, the environment variables are still active, but the visual indicator in the `PS1` prompt is gone. Also, cleanup functions like `deactivate` have vanished. – Kevin J. Chase Sep 26 '16 at 12:50
2

This works for my Cygwin + win7. Thanks! Typing this faster that typing . ~/.bashrc – Danniel Little Mar 15 '17 at 19:45
Will this work for another session I open after running 'exec bash' in my current session ? – nitinr708 Aug 01 '17 at 08:45
1

just to add, use: exec $SHELL -l; as $SHELL returns bash in this instance. – Jimmy MG Lim Jun 01 '19 at 23:08
1

This worked. Super nice, short, solid. `source` did not work for some reason. – lowtechsun Aug 28 '19 at 17:00
1

That worked perfectly for me when the source option wasn't working, this is exactly what I was looking for! Thank you, that way I don't have to restart terminal and use bash whenever absolutely necessary! Thanks again – Iakovos Belonias Mar 02 '20 at 12:39
1

@whosayin thx! this just helped me with executing ansible-playbooks that were no longer accepting arguments that had worked previously. – ficestat Aug 25 '20 at 22:20

mklement0 · Answer 3 · 2021-04-28T12:40:18.680

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.

^{[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 not likely in this case), you don't strictly need double quotes, but using them is a good habit to form.}

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 07 '16 at 08: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 01 '17 at 08:49
@nitinr708: Yes, `exec $BASH` will source `~/.bashrc`, so you'll see its changes to the shell environment in the new session. — mklement0, Aug 01 '17 at 12:45

Randy Proctor · Answer 4 · 2018-01-25T13:26:56.260

46

Someone edited my answer to add incorrect English, but here was the original, which is inferior to the accepted answer.

. .bashrc

edited Jan 25 '18 at 13:26

answered Mar 25 '10 at 17:59

Randy Proctor

6,688
2
21
26

29

This will only work if your current directory is actually your home directory. The following will work: . ~/.bashrc – Brian Showalter Mar 25 '10 at 18:09
6

What makes this work? What is actually happening when I do ". .bashrc"? Thanks! – Jed Daniels Mar 25 '10 at 18:34
56

. is a BASH shortcut for the "source" builtin command. So ". .bashrc" is the same as "source .bashrc" to the BASH interpreter. – Brian Showalter Mar 25 '10 at 18:45
8

Cool. Thanks. Now that I didn't know. – Jed Daniels Mar 25 '10 at 18:49
3

I just submitted an edit request to add `~/`, but since the top answer shows both `source ~/.bashrc` and `. ~/.bashrc` I wonder if this answer should just be deleted as redundant. – Max Ghenis Dec 01 '16 at 00:04
1

@RandyProctor: While it's commendable that you point out that your answer is inferior to the accepted one, it would be even better if you simply _deleted_ it, given that it's not only distinctly inferior (due to only working if the current dir. _happens to be_ the current user's home dir., as stated), but, conversely, _adds nothing_ of interest. – mklement0 Mar 24 '19 at 21:00

Roy Lin · Answer 5 · 2016-05-26T22:24:02.730

19

With this, you won't even have to type "source ~/.bashrc":

Include your bashrc file:

alias rc="vim ~/.bashrc && source ~/.bashrc"

Every time you want to edit your bashrc, just run the alias "rc"

edited May 26 '16 at 22:24

answered Feb 29 '16 at 19:39

Roy Lin

670
8
17

score 19 · Answer 6 · answered Mar 08 '12 at 11:51

19

Depending on your environment, just typing

bash

may also work.

answered Mar 08 '12 at 11:51

James

2,240
1
20
21

16

However, this will invoke a new shell within the current one, thus wasting resources. Better use @WhoSayln's [exec](http://www.gnu.org/software/bash/manual/bashref.html#index-exec) solution which **replaces** the current shell with the newly invoked one. – Bernhard Wagner Sep 04 '13 at 09:45
1

yeah just use source. This is entirely unnecessary and annoying. – dylnmc Sep 23 '14 at 20:50
In addition to @BernhardWagner's comment, you also loose your current bash history if your spawn a new shell – peterchaula May 06 '17 at 12:45
This is good solution whereby user privilege access is limited. – Tunde Pizzle Oct 18 '18 at 07:36
1

invoking a subprocess adds a layer of complexity that has no additional value. – Alan Berezin Jan 02 '20 at 00:07

Geoffrey Hale · Answer 7 · 2018-09-14T17:36:26.970

16

. ~/.bashrc

. is a POSIX-mandated builtin

Alternatives

source ~/.bashrc

source is a synonym for dot/period . in bash, but not in POSIX sh, so for maximum compatibility use the period.

exec bash

exec command replaces the shell with a given program... – WhoSayIn

edited Sep 14 '18 at 17:36

answered Feb 14 '17 at 21:34

Geoffrey Hale

8,152
4
34
42

2

`exec bash` still inherits the environment of the current shell. `exec env -i bash` would be closer (or `exec env -i bash -l` if you are currently in a login shell). – chepner May 16 '17 at 20:42

score 7 · Answer 8 · answered Jun 01 '19 at 23:09

7

exec bash is a great way to re-execute and launch a new shell to replace current. just to add to the answer, $SHELL returns the current shell which is bash. By using the following, it will reload the current shell, and not only to bash.

exec $SHELL -l;

answered Jun 01 '19 at 23:09

Jimmy MG Lim

1,167
12
14

score 6 · Answer 9 · answered Oct 04 '18 at 12:11

Depending upon your environment, you may want to add scripting to have .bashrc load automatically when you open an SSH session. I recently did a migration to a server running Ubuntu, and there, .profile, not .bashrc or .bash_profile is loaded by default. To run any scripts in .bashrc, I had to run source ~/.bashrc every time a session was opened, which doesn't help when running remote deploys.

To have your .bashrc load automatically when opening a session, try adding this to .profile:

if [ -n "$BASH_VERSION" ]; then
    # include .bashrc if it exists
    if [ -f "$HOME/.bashrc" ]; then
        . "$HOME/.bashrc"
    fi
fi

Reopen your session, and it should load any paths/scripts you have in .bashrc.

I have this in ".profile" but it's not working — each time I exit, I have to do it by hand. Any suggestions? — Wayne Smallman, Jul 04 '19 at 13:59

jwismar · Answer 10 · 2019-03-25T12:35:12.573

4

type:

source ~/.bashrc

or, in shorter form:

. ~/.bashrc

edited Mar 25 '19 at 12:35

answered Mar 25 '10 at 18:00

jwismar

11,772
3
28
42

2

Again, works only if you are in the home directory, or more precisely, in the directory where `.bashrc` is located. A more correct way to do this, as told in the accepted answer, is `source ~/.bashrc`. – John Red May 20 '16 at 17:12

SherylHohman · Answer 11 · 2018-11-12T19:07:03.227

I used easyengine to set up my vultr cloud based server.
I found my bash file at /etc/bash.bashrc.

So source /etc/bash.bashrc did the trick for me!

update

When setting up a bare server (ubuntu 16.04), you can use the above info, when you have not yet set up a username, and are logging in via root.

It's best to create a user (with sudo privledges), and login as this username instead.
This will create a directory for your settings, including .profile and .bashrc files.
https://linuxize.com/post/how-to-create-a-sudo-user-on-ubuntu/

Now, you will edit and (and "source") the ~/.bashrc file.

On my server, this was located at /home/your_username/.bashrc
(where your_username is actually the new username you created above, and now login with)

score 3 · Answer 12 · answered Aug 08 '18 at 20:13

3

For me what works when I change the PATH is: exec "$BASH" --login

answered Aug 08 '18 at 20:13

Cecília Assis

121
1
10

The question is about reloading `~/.bashrc`, which `--login` will _not_ (directly) reload; at a user level, it'll reload `~/.bash_profile` (or `~/.bash_login` or `~/.profile`) instead. – mklement0 Mar 24 '19 at 21:07

score 2 · Answer 13 · answered Oct 02 '14 at 20:32

2

i use the following command on msysgit

. ~/.bashrc

shorter version of

source ~/.bashrc

answered Oct 02 '14 at 20:32

Sojan Jose

3,054
6
30
45

@jwg the accepted answer is . .bashrc . will work only if you are in the home directory on msysgit. – Sojan Jose Oct 09 '14 at 17:15
@jwg ok i thin i was mentioning that you don't have to type 'source ~/.bashrc' instead use the shorter version . – Sojan Jose Oct 09 '14 at 17:21
@jwg okay i added it as edit to the original answer :) – Sojan Jose Oct 09 '14 at 19:28
1

Why the redundant answer @Sojan ? – nitinr708 Aug 02 '17 at 14:24
@nitinr708 2014 . i barely remember :P . the original answer was edited later something i guess. – Sojan Jose Aug 06 '17 at 20:30

beattidp · Answer 14 · 2018-11-14T01:04:56.990

2

Assuming an interactive shell, and you'd like to keep your current command history and also load /etc/profile (which loads environment data including /etc/bashrc and on Mac OS X loads paths defined in /etc/paths.d/ via path_helper), append your command history and do an exec of bash with the login ('-l') option:

history -a && exec bash -l

edited Nov 14 '18 at 01:04

answered Nov 14 '18 at 00:57

beattidp

43
5

score 1 · Answer 15 · edited Mar 21 '15 at 19:16

1

This will also work..

cd ~
source .bashrc

edited Mar 21 '15 at 19:16

Timo Tijhof

9,597
6
31
45

answered Mar 04 '14 at 13:15

kirti

35
3

9

It does, but it also changes the working directory to ~, which is not wanted. – Albin Jun 03 '14 at 15:37
1

Thank you for keeping the context alive @Krinkle – nitinr708 Aug 03 '17 at 10:51
Is it necessary to specify `~` to change the working directory to the user home directory? – Kenly Aug 16 '18 at 13:55

score 1 · Answer 16 · answered May 22 '18 at 13:53

I noticed that pure exec bash command will preserve the environment variables, so you need to use exec -c bash to run bash in an empty environment.

For example, you login a bash, and export A=1, if you exec bash, the A == 1.

If you exec -cl bash, A is empty.

I think this is the best way to do your job.

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

16 Answers16

Alternatives

Linked

Related