There are four ways to execute a shell script. Each way has it’s own meaning as explained in this article.
1. Execute Shell Script Using File Name
Use the shell script file name to execute it either by using it’s relative path or absolute path as shown below.
$ cd /home/sathiya $ ./scriptfile (or) $ /home/sathiya/scriptfile
If you have the shebang, then it will be executed using the command interpreter specified in the shebang. If you are beginner in shell scripting, refer our earlier article Shell Script Execution Guidelines for Newbies
2. Execute Shell SCript by Specifying the Interpreter
You can also execute a unix shell script by specifying the interpreter in the command line as shown below.
Execute using sh interpreter
$ sh scriptfile
Execute using bash interpreter
$ bash scriptfile
Irrespective of what is being used as shebang, the interpreter which you have specified will be used for execution. You can use any interpreter (sh, ksh, bash, csh etc.,).
3. Execute Shell Script Using . ./ (dot space dot slash)
While executing the shell script using “dot space dot slash”, as shown below, it will execute the script in the current shell without forking a sub shell.
$ . ./scriptfile
In other words, this executes the commands specified in the scriptfile in the current shell, and prepares the environment for you.
“dot space dot slash” Usage Example:
Typically we use this method, anytime we change something in the .bashrc or .bash_profile. i.e After changing the .bashrc or .bash_profile we can either logout and login for the changes to take place (or) use “dot space dot slash” to execute .bashrc or .bash_profile for the changes to take effect without logout and login.
$ cd ~ $ . ./.bashrc $ . ./.bash_profile
4. Execute Shell Script Using Source Command
The builtin source command is synonym for the . (dot) explained above. If you are not comfortable with the “dot space dot slash” method, then you can use source command as shown below, as both are same.
$ source ~/.bashrc
Which method do you prefer to execute a shell script?
My name is Ramesh Natarajan. I will be posting instruction guides, how-to, troubleshooting tips and tricks on Linux, database, hardware, security and web. My focus is to write articles that will either teach you or help you resolve a problem. Read more about
Comments on this entry are closed.
Hi there!
Thanks for posting (as always) such a nice and useful article. 🙂
Well… I like using ./ (dot slash) syntax when executing shell scripts. So, if the script being executed has the shebang, I don’t need to worry about which interpreter to use. The script itself has the responsibility to specify the right interpreter for its execution to succeed. However, there is an disadvantage in this method. If the path to the interpreter in an environment on which this kind of script is going to be executed is different to the path specified in the shebang section of the script, then things may not occur as expected. Therefore, it’s important to know a little bit more about ways of executing shell scripts… and you helped us a lot by posting this article.
Probably something even more relevant than anything else about the last two options, it’s not just used for when you want to take advantage of changes to .profile, .bash_profile etc. Sourcing a script using:
. ./ (dot space dot slash or dot space /
or
source
will cause any shell variables defined AND exported by the script being sourced to be changed, and remain in the shell environment. People sometimes have for example an Oracle or Java environment setup script. Sometimes they run one script which calls the other environment setup script without sourcing it, and the variables are not defined when control returns to the calling script. This sometimes causes newbies (and experienced people who forget!) to waste time debugging a script, or end up combining the two scripts into one.
When the calling script sources the environment setup script, sourcing causes all EXPORTED variable to remain after the second script terminates. Some people might ask how this is useful, why not just put the environment definitions into the first script. The simple answer is that sourcing can reduce or eliminate the chance of multiple configurations, and something being missed in one of many scripts if something changes. Back to the Oracle example, if a DBA needs the environment defined each time they log in, but also needs the same environment defined for any scripts they run whether via the shell or scheduled via cron, they can create a file $ORACLE_HOME/oraenv which is a single source of truth for all necessary variables and a single place to make changes. From their .profile, .bash_profile etc, as well as from all scripts, near the start of script execution they call
. $ORACLE_HOME/oraenv (dot space $ORACLE_HOME/oraenv)
and all the necessary shell variable will be consistent, and available to all calling scripts. With a single place to make changes, when an Oracle or Java version changes, a home directory, a utility name etc. – a single change can easily apply the necessary change without editing what could easily be hundreds of scripts.
I should have realized the web site might see <script> and filter them! My examples above were:
Sourcing a script using:
. ./[script] (dot space dot slash [script] or dot space /[full path]/[script]
or
source /[full path]/[script]
Hi Ramesh,
first of all, I´d like to thank you for writing this blog. It´s a source of Inspiration for anyone who works with Linux.
a little Add to this post (maybe altough new for you?!):
While debuging, like executing my shell scrips via sh -x scriptname.
I saw that for the first time. whats the difference between:
$ cd ~
$ . ./.bashrc
and this (which is shorter)
$ cd ~
$ . .bashrc
. ./.bashrc can be shortened to simply . .bashrc. No need to make this more complicated than needed.
The main reason to use the ./ when executing a script or other executable file, is when the executable is in the current directory, when the current directory is not in the executable path ($PATH). Since the ‘.’ command is a bash builtin, you are passing the filename to it as an argument, not attempting to execute the filename on it’s own.
I didn’t remember the “. ./” method ! I always use “source”.. thanks a lot guys, these articles are very helpful!
THanks for the explanation of the dot space dot slash thing!
i am getting error when iam executing ./script but same gets executed when i give sh script name . ia m getting below error with ./script
/home/infaadmin/.bash_profile[3]: .[5]: .[8]: [: argument expected
/home/infaadmin/.bash_profile[3]: .[5]: .[40]: shopt: not found [No such file or directory]
Dot Space Dot (. ./)
Any one help me … i am using ksh script in Sunos
i am exporting few variables in from the script … when i echo the variables its content is NULL ….
Then i used . ./filename … it works fine …
Problem occurs here — filename script requires sudo permission for some part …
if execute sudo . ./filename
its throwing error some thing like this — > sudo: . command not found
Plz help me out
Hi Satish, you’ll find sudo often doesn’t like ‘source’ (official name of the . ./foo.sh notation). You may have to add it to the list of available sudo commands. Apologies if I’m completely wrong.
Very useful and concise article. I was looking all over for dot space dot usage in the .bashprofile file
Hey, this was mentioned earlier but I thought to summarize.
source can change environment variables. Like your PATH.
Thanks, nice post!
Thank you a lot !!!
It is very useful.
Thank you a lot !!!