34
  1. I was wondering if the following two ways of running a bash script are equivalent?

    . ./myScript.sh
    
    source myScript.sh
    
  2. Are they both running the content of the script instead of running the script, i.e. not creating a subshell for running the script?
6
  • 1
    Hey, that's in the manpage!
    – alex
    Commented Aug 1, 2011 at 18:37
  • @alex: show me please? man ., man source or whatever I haven't know yet.
    – Tim
    Commented Aug 1, 2011 at 18:39
  • 2
    See type . and help . Commented Aug 1, 2011 at 18:43
  • man $SHELL, /source
    – alex
    Commented Aug 1, 2011 at 20:42
  • 4
    . is more portable according to others.
    – l0b0
    Commented Aug 2, 2011 at 10:49

3 Answers 3

28
  1. They are equivalent in bash in that they do exactly the same thing. On the other hand, source is 5 characters longer and is not portable to POSIX-only shells or Bourne whereas . (dot) is, so I never bother using source.

  2. That is correct - sourcing a file runs the commands in the current shell and it will affect your current shell environment. You can still pass arguments to the sourced file and bash will actually look in $PATH for the file name just like a normal command if it doesn't contain any slashes.


Not related to the original question of . vs source, but in your example,

. ./myScript.sh 

is not identical to

source myScript.sh

because while . and source are functionally identical, myScript.sh and ./myScript.sh are not the same. Since ./myScript.sh contains a slash, it's interpreted as a path and the shell just uses ./myScript.sh. However, myScript.sh does not have a slash so the shell does a $PATH search for it first. This is the POSIX specified standard behavior for .. Most shells default to this although they may add extensions (such as searching in the current working directory after the path search) or options to change the behavior of ./source.

2
  • 2
    the behavior when the provided path of the file doesn't contain a / is shell-dependent and for bash and zsh depends on whether the POSIX mode is enabled or not. Also note that in many ksh implementations, . behaves differently from source. Commented Dec 14, 2012 at 20:12
  • @StephaneChazelas Yes, you are right. I added a note to clarify that it the above description is of the POSIX standard.
    – jw013
    Commented Dec 14, 2012 at 20:21
8

Yes, they are equivalent. There is no functional difference; . is just a builtin synonym for source.

(Edit: Apparently this is only true for bash and zsh. Some lighter shells don't have source, only . is specified by POSIX so ksh, dash, ash, etc. may not have source. See jw013's answer for info.)

2
  • Thanks! But $ alias . outputs bash: alias: .: not found .
    – Tim
    Commented Aug 1, 2011 at 16:57
  • That is they are both builtins and the alias is builtin too. This is documented, but I guess 'synonym' is the right term in this case, not 'alias'.
    – Caleb
    Commented Aug 1, 2011 at 17:00
-1

What is the difference between '.' and 'source' in shells?

For bash, . and source behave the same, but their behaviour is affected by whether they are run in POSIX mode or not¹.

POSIX requires that the . command exits the shell process² if it can't open the file for reading and requires that the file be found through a search of the directories in $PATH if the provided path doesn't contain a /.

csh's source interprets the argument as a path, and never looks the file up in $PATH.

bash . and source behave as POSIX requires when in POSIX mode, and as pdksh's source when not, that is they don't exit the script if they fail to open the file for reading (same as command .) and lookup the file in $PATH and the current directory if the provided path doesn't contain a /.

zsh . behaves as POSIX requires, while source looks in the current directory first and then $PATH (even in csh emulation) when the argument doesn't contain a /. (see info zsh . and info zsh source for details). If . or source fail to find/open the file, that only aborts the shell when in POSIX mode (sh emulation) though.

You must log in to answer this question.

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