I have built and installed a new piece of software manually (from a remote git repository). Every time I want to use it, I run something like,

. /path/to/setup_software.sh

but I would like that to happen automatically every time I log into my account, instead of doing it manually. I have tried to put the command above inside my .bashrc file, so that the setup file is sourced every time I open my kernel. Everything works fine after that and I am happy. My only minor (really minor) problem is that it prints some log messages just after when I open the kernel and the whole sourcing takes some time (which I don't like having :D). Anyways, I am assuming there is a neater solution out there, perhaps moving my installation folder to somewhere that runs the setup file automatically; any help would be greatly appreciated.

4 Answers 4


Placing the source (or .) command in a startup file other than .bashrc will not help the execution time. You can place the startup in /etc/profile.d but the delay will be the same. As for the log messages, try this in .bashrc

. /path/to/setup_software.sh >/dev/null 2>&1

You will not see the log messages. You also will not see any errors that crop up.


You'll just want to put it into ~/.bash_profile, as that's what your shell executes on login; problem: if you're not logging into a shell (e.g. because you log on using a graphical interface), then that's not going to be run.

remark: this is one of three separate answers; the separateness is intended.


If you know that your script only sets things that are both

  1. environment variables, and not new shell functions,
  2. do not ever change (e.g. don't depend on time, or date, or the version number of something you might update),

then you can simply "emulate" what the script does: it will set a few environment variables.

So, how to compare what the environment variables are before and after running your script? diff is really good at comparing text files.

You can use set to give you the environment variables (after setting the posix option.

And you can use <(...) to make a temporary file to hold the result of set run in a subshell. So, put all that together:

$ diff <(set -o posix; set) <(export FOO=BAR; set -o posix; set)

will tell you


which you'd read as "there's a line FOO=BAR that's there in the second output, not in the first".

You can run

$ diff <(set -o posix; set) <(. /path/to/setup_software.sh; set -o posix; set)

to figure out what your setup script changed in the environment. You'll need a human brain to interpret that – some things will just be irrelevant, some will be what the script actually does to your system that has an influence.

You can then add all the changed variables in your ~/.bashrc, e.g.

export FOO=BAR

remark: this is one of three separate answers; the separateness is intended.


This sounds dangerously much like you're trying to too much! You could just add an alias that sources the script and then starts your software:

alias startit=". /path/to/setup_software.sh; run_software"

and then call startit.

If it's more than just one command, it might be the case that you're looking for something like auto-activating environments when you cd into specific folders.

direnv allows you to do pretty much that. Of course, it doesn't solve the issue that sourcing the script takes time - but it only does it once when you enter a specific directory, and not after for the same shell.

remark: this is one of three separate answers; the separateness is intended.

You must log in to answer this question.

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