For example, I have a function in my .bashrc file:

function open_bashrc() {
    gedit ~/.bashrc
    source ~/.bashrc

So anywhere I am, if I type open_bashrc, then it will open the .bashrc file. I can open it and change it, but after I save and click close, it doesn't do the second step source .bashrc. Rather I have to type source ~/.bashrc myself. Why? What's wrong with the function?

  • 1
    Shouldn't it be (in the function) source ~/.bashrc or source $HOME/.bashrc to ensure it does it from anyplace you edit?
    – KevinO
    Jul 1, 2017 at 0:23
  • Seems like a good Answer, KevinO!
    – Jeff Schaller
    Jul 1, 2017 at 0:39
  • @KevinO I tried that but that didn't seem to work either. Basically after I run open_bashrc, gedit opens, and once I close the file, the function stops so I don't even think it reaches the next line
    – K Split X
    Jul 1, 2017 at 0:40
  • How exactly are you testing the edits? In using the function as described above (with the modification to the source) with gedit, and adding an export GO=TEAM, it adds the expected variable. What does type -f gedit reveal? And please clarify the statement that the "function stops" since to me that would imply the shell was locked as the function never returned.
    – KevinO
    Jul 1, 2017 at 0:55
  • 2
    I can not make the function fail to correctly source the file edited. Please note: in the present running shell !. How do you detect the sourcing has failed?
    – user232326
    Jul 1, 2017 at 2:16

2 Answers 2


I have this in my aliases file and it works:

alias bashrc='vim ~/.bashrc && source ~/.bashrc'

  • @polvoazul : Whether you have it in an alias or in a shell function, doesn't make any difference. Jul 3, 2017 at 9:21

Could it be, that in your execution context, gedit is not resolved as the executable gedit program, but as a shell script, function or alias, which executes gedit in the background? Otherwise, I see no reason, why source should not be executed.

Actually, I would not use &&, as polvoazul suggested. This solution would have the effect, that the .bashrc is sourced only if gedit returns with exit code zero. While we certainly should hope, that a well-behaved program should exit with 0 if everything went well, I have seen more enought programs which don't care about exit codes, and the man page of gedit is silent about the exit code, which, technically, means that the exit code is unspecified. This is not something I would like my functions to depend on....

  • What do you mean executes in the background? If I type in gedit ~/.bashrc in terminal, then at that very moment, terminal stops taking commands, and waits till I physically close out of gedit and then it can resume. Is this counted as background?
    – K Split X
    Jul 3, 2017 at 13:31
  • No, in this case, it's not background, and the source command must have been executed. Did you try to turn on tracing (set -x) inside the function? Jul 3, 2017 at 16:25
  • I'm really just have the line that polvoazul provided me in my .bashrc file, nothing more
    – K Split X
    Jul 3, 2017 at 17:01
  • In defense of &&: I actually want to source the file ONLY if vim exited correctly. Imagine if it crashes for any reason, better not to source a file in a mid-edit state! Also, I don't know of any code editor that doesn't respect 0 = OK status code.
    – polvoazul
    Aug 22, 2021 at 18:17

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .