91

I frequently edited the .bashrc file to export new environment variables.

Rather than close the console and start a new one to refresh the env variables, is there a convenient way to refresh?

xiaohan2012
  • 1,705
  • I just want to mention that environment variables should be set in your .profile, not .bashrc. The .profile is sourced when you login (e.g. via a display manager) and also takes effect for programs that aren't started from your shell (e.g. via your desktop environment). This makes it, AFAICT, basically impossible to modify it without logging out though. Then only solution to change the environment after login I'm aware of is the fish shell with their universal variables. This shell is not well supported in display managers though (yet?). – Paul Schyska Mar 07 '21 at 04:31

5 Answers5

119

Within the same window, you can simply type bash to start a new one. This is equivalent to closing the window and re-opening a new one.

Alternatively, you can type source ~/.bashrc to source the .bashrc file.

nopcorn
  • 9,559
  • 9
    No need to execute another shell. source is the correct way – Matteo Dec 13 '11 at 06:18
  • 3
    also there is no need to type long word source. you can just type dot instead of it: . ~/.bashrc. – rush Dec 13 '11 at 06:31
  • 7
    @Rush typing source shows the user which command is called. I don't believe in showing the shorthanded commands to new users until they understand what the code is doing. – nopcorn Dec 13 '11 at 06:34
  • 16
    note that merely sourcing bashrc is not necessarily equal to a restart of bash. defined variables are not automatically undefined. shell options are not automatically unset. sourcing bashrc only executes what is written in bashrc. it does not rollback any other changes in the environment. starting a new bash session inside the old is also not necessarily equal to a restart of bash, as the new process inherits the environment from the old. – Lesmana Dec 13 '11 at 20:57
  • 4
    @MaxMackie Considering how source is a bashism that is longer to type yet offers no advantages over its portable across all shells equivalent, ., I don't see the point of encouraging anyone, new or experienced, to use it. – jw013 Dec 15 '11 at 02:27
  • For some reason source not working in a a shell script inside an if else statement. Is it possible to fix this? – Lanti Dec 23 '15 at 10:35
  • 3
    @n0pe This is equivalent to closing the window and re-opening a new one. i don't think that is true, because the new bash shell is executed inside the old, therefore the old doesn't die. Instead when closing a terminal, the bash session of that terminal is killed, therefore in your GUI exacmple there does only one bash exist afterwards. – uuu Jun 22 '16 at 10:38
  • 1
    exec bash or exec bash -l will be equivalent. @toogley – Kusalananda Jun 22 '16 at 11:04
  • To complement @lesmana's comment, it is possible to start a new child shell via bash that does start out with a clean environment, using env -i bash. From the env manpage: -i, --ignore-environment --> start with an empty environment – waldyrious Nov 09 '17 at 11:04
  • 1
    This is NOT EQUIVALENT. You are EXECUTING A COMMAND WITHIN THIS PROCESS. THIS CREATES A CHILD PROCESS IN THE MEMORY. It may be functionally the same for the user's assumed needs, but NEVER ASSUME THE NEEDS OF THE USER when there is a technical difference that could come back to confuse the user. The user will not be pleased when he/she has to type the "exit" command two times at the end of his/her terminal session, and wonders why this is so. – Ryan Jul 03 '20 at 07:08
  • 2
    This only adds the newly added variables, but doesn't remove the variables removed in bashrc file. – Taha Rehman Siddiqui Oct 27 '20 at 01:31
26

Just use

source ~/.bashrc

or

. ~/.bashrc
Matteo
  • 9,796
  • 4
  • 51
  • 66
  • 2
    this is not right, as the objects you may already have defined in your session but that are not redefined in the bashrc file (or unset) will stay defined – Jules Gagnon-Marchand May 25 '21 at 00:57
5

In addition to what others have suggested, I have found out that source won't unset the previously assigned environment variables. So, if you want to unset environment variables, you have to do it manually using unset <var>.

Lokesh
  • 221
  • 6
  • 16
  • Great idea! But this exposes what I hate the most about Linux mindset. They make tools to do a half-assed job and then someone has to come around and clean up the mess. Mutating the state of your system is NOT FUNDAMENTAL. Refreshing an environment by starting from a known good state is a fundamental concept in computer science and yet the UNIX developer mindset chooses to ignore this. The state of the system needs to be a guarantee! Not just merely an afterthought. – Ryan Jul 03 '20 at 07:48
5

Adding to another answer, I find it's helpful to define the following alias:

alias refreshenv="bash;exit"

Doing this will ensure that the parent bash instance will be killed as soon as you exit the child bash instance and so on. Avoids you having to type exit multiple times, as you'd have to do with just typing bash.

Top Cat
  • 191
  • Could you change the "another answer" into a link to that answer? ;) – AdminBee Jan 28 '20 at 12:14
  • Interesting hack. Definitely a workable equivalent. It's what you do anyway, closing terminal and opening it back up. – Ryan Jul 03 '20 at 07:50
4

Since this question comes up on Google when you search for how to reload the environment inside a shell script, here's one:

If you're inside a Bash script and need to re-load environment variables afresh:

Spawn a login shell with an empty environment and then examine its state:

eval "$(exec /usr/bin/env -i "${SHELL}" -l -c "export")"

Note that this will not consider non-exported variables. I would suggest set -o posix && set for that instead, but it has the problem that it can break, as you can't just write every variable in Bash. Parsing its output is not easy either, so I wouldn't recommend it. It's unlikely it's what you want though.

user541686
  • 3,083