≡ Menu

4 Ways of Executing a Shell Script in UNIX / Linux

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?

Add your comment

If you enjoyed this article, you might also like..

  1. 50 Linux Sysadmin Tutorials
  2. 50 Most Frequently Used Linux Commands (With Examples)
  3. Top 25 Best Linux Performance Monitoring and Debugging Tools
  4. Mommy, I found it! – 15 Practical Linux Find Command Examples
  5. Linux 101 Hacks 2nd Edition eBook Linux 101 Hacks Book

Bash 101 Hacks Book Sed and Awk 101 Hacks Book Nagios Core 3 Book Vim 101 Hacks Book

Comments on this entry are closed.

  • Rod July 20, 2010, 6:02 am

    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.

  • Homer July 20, 2010, 6:53 am

    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.

  • Homer July 20, 2010, 6:57 am

    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]

  • Quinn July 20, 2010, 7:32 am

    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.

  • Tod July 20, 2010, 8:49 am

    I saw that for the first time. whats the difference between:
    $ cd ~
    $ . ./.bashrc

    and this (which is shorter)
    $ cd ~
    $ . .bashrc

  • Rick Stanley July 20, 2010, 8:56 am

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

  • roko July 22, 2010, 7:34 am

    I didn’t remember the “. ./” method ! I always use “source”.. thanks a lot guys, these articles are very helpful!

  • joanne December 28, 2011, 12:51 am

    THanks for the explanation of the dot space dot slash thing!

  • Prashant February 24, 2012, 4:08 am

    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]

  • satish June 27, 2012, 5:42 am

    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

  • Count Ludwig July 10, 2012, 7:25 am

    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.

  • Siddhartha June 21, 2013, 2:49 pm

    Very useful and concise article. I was looking all over for dot space dot usage in the .bashprofile file

  • Kin January 19, 2014, 7:12 pm

    Hey, this was mentioned earlier but I thought to summarize.

    source can change environment variables. Like your PATH.

  • Binh Thanh Nguyen February 6, 2014, 2:29 am

    Thanks, nice post!

  • Ghennadii May 6, 2015, 3:36 am

    Thank you a lot !!!
    It is very useful.

  • Allen January 5, 2016, 10:44 am

    Thank you a lot !!!