ChatGPT解决这个技术问题 Extra ChatGPT

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

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


H
Harry B

You can enter the long form command:

source ~/.bashrc

or you can use the shorter version of the command:

. ~/.bashrc

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 - 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").
@Alex you can automate it by adding the line ~/.bashrc into ~/.bash_profile, though I don't know if this is a good practice.
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.
It will affect only the current terminal.
J
Jonathan Gilbert

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


Could you please explain the difference of source .bashrc command and exec bash?
@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)
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!
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.
@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.
m
mklement0

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.

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.

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.


You answered my question before I could ask it. This is good to know; I often set my CLASSPATH for a single session.
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: Yes, exec $BASH will source ~/.bashrc, so you'll see its changes to the shell environment in the new session.
This is why I use broadcast all + source. Best of both worlds, imo.
@i_want_more_edits: $SHELL reflects whatever shell is the current user's default shell, which may or may not be Bash.
R
Randy Proctor

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

. .bashrc

This will only work if your current directory is actually your home directory. The following will work: . ~/.bashrc
What makes this work? What is actually happening when I do ". .bashrc"? Thanks!
. is a BASH shortcut for the "source" builtin command. So ". .bashrc" is the same as "source .bashrc" to the BASH interpreter.
Cool. Thanks. Now that I didn't know.
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.
R
Roy Lin

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"


J
James

Depending on your environment, just typing

bash

may also work.


However, this will invoke a new shell within the current one, thus wasting resources. Better use @WhoSayln's exec solution which replaces the current shell with the newly invoked one.
yeah just use source. This is entirely unnecessary and annoying.
In addition to @BernhardWagner's comment, you also loose your current bash history if your spawn a new shell
This is good solution whereby user privilege access is limited.
invoking a subprocess adds a layer of complexity that has no additional value.
G
Geoffrey Hale
. ~/.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


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

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;

Just to state it explicitly: $SHELL reflects the current user's default shell, so this is a way to replace the current session - whatever shell's process it may be - with a new session of the user's default shell. -l makes the new session a login session, which is appropriate on macOS (and by default only loads ~/.bash_profile, not also ~/.bashrc), but not on Linux.
V
Vincent Doba

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 privileges), and login as this username instead.
This will create a directory for your settings, including .profile and .bashrc files as described on the previous ressource.

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)


i
i_want_more_edits

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?
C
Cecília Assis

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


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.
S
Sojan Jose

i use the following command on msysgit

. ~/.bashrc

shorter version of

source ~/.bashrc

@jwg the accepted answer is . .bashrc . will work only if you are in the home directory on msysgit.
b
beattidp

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

C
CatDog

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.


Is exec -c the same as exec -cl?
j
jan-glx

I understand you want a shell as after logging out and in again. I believe the best way to achieve that is:

exec env -i HOME="$HOME" "$SHELL" -l

exec will replace the current shell, such that you are not left with it when the new one exits. env will create a new empty environment, with -i we add $HOME so that your shell (usually bash) given by $SHELL can find ~/.profile/~/.bash_profile (and thus (on ubuntu or if specified) ~/.bashrc). Those will be sourced thanks to -l. I'm not completely sure though.


T
Timo Tijhof

This will also work..

cd ~
source .bashrc

It does, but it also changes the working directory to ~, which is not wanted.
Is it necessary to specify ~ to change the working directory to the user home directory?
N
ND Geek

I wrote a set of scripts I called bash_magic that automates this process across numerous shells. If you update a shell file in the bash magic shell directory (.bash.d by default), it will automatically source the update at the next prompt. So once you've made a change, just hit the Enter/return key and any updates will be sourced.