While following android eclipse debug tutorial, I encounter following commands.

cd /path/to/android/root 
. build/envsetup.sh 
lunch 1    

My problem is what the dot before build/envsetup.sh means?


A dot in that context means to "source" the contents of that file into the current shell. With source itself being a shell builtin command. And source and the dot operator being synonyms.


Say I had the following contents in a sample.sh file.

$ cat sample.sh 
echo "hi"
echo "bye?"

Now when I source it:

$ . sample.sh 

Files such as this are often used to incorporate setup commands such as adding things to ones environment variables.


Say I had these commands in another file, addvars.sh.

$ cat addvars.sh 
export VAR1="some var1 string"
export VAR2="some var2 string"

Notice that I don't have any variables in my current shell's environment.

$ env | grep VAR

Now when I source this file:

$ . addvars.sh 

OK, doesn't seem like it did anything, but when we check the env variables again:

$ env | grep VAR
VAR1=some var1 string
VAR2=some var2 string

To add to slm's answer:

There are two ways to run a shell script. One is to run the script in a separate process, which means anything about the shell's environment (memory state) will revert to the state of the "parent" shell before running the "child" shell process.

For example, the current working directory (the location in the filesystem one is in) is determined on a per-process basis. So, let's have a script that looks like this:

cd ~
cd ..

So, let's call this script, oh, foo. And let's run this script as follows: ./foo

We will see the following:


(Standard disclaimer that there are a large number of Linux and other UNIX clone distributions out there, some of which do not put user's directories in /home. Or, as we used to say "Your mileage may vary")

Now, after running this script, let's type in this command


To see which directory we are in. We will see something like this:


The reason being, again, the shell script we ran had its own environment (including its own directory where commands were being run), and that environment went away once the script finished running.

Now, let's run the foo script like this

. ./foo

Or, equivalently:

source ./foo

If we do a pwd afterwards, we will see this:


The reason being: Sourcing a script doesn't call a separate process. It is like typing all of the commands in the parent process by hand; its environment is preserved after the script ends.

Let me come up with a simpler example. Let's have a script that looks like this:


Let's name it foo. Let's make sure we can run it: chmod 755 foo. Then, let's run it like this:


Nothing happens. However, on the other hand, if we do this:

. ./foo

Or this:

source ./foo

We log out.

  • 14
    Your answer is better than the accepted one, I understood how you explained, thanks! – Ahmed Jul 25 '16 at 13:03
  • 4
    Dun-da-da-duuuun! (drumroll please)...and the most important phrase here of all is!: The reason being: Sourcing a script doesn't call a separate process. It is like typing all of the commands in the parent process by hand; its environment is preserved after the script ends. – Gabriel Staples Oct 25 '19 at 2:36
  • 2
    You should lead with the second example. It packs more punch. – MonoThreaded Oct 29 '19 at 14:11

The period (dot) is short hand for the bash built in source. It will read and execute commands from a file in the current environment and return the exit status of the last command executed. The files can be in the current directory or anywhere in the PATH. It does not need to be executable.

  • "The files can be in the current directory or anywhere in the PATH". Hum sourcing a file can be done no matter where the file is in the entire filesystem, you just provide the full path to it. – Atralb Apr 12 '20 at 11:21


The dot is the same as the source command.

source is a Unix command that evaluates the file following the command, as a list of commands, executed in the current context.

Extracted from https://en.wikipedia.org/wiki/Source_(command)

  • 3
    Welcome to U&L! This answer duplicates information that's already in the accepted answer, and doesn't really add anything. – JigglyNaga Dec 13 '18 at 17:06
  • with respect, although technically Jiggly is correct - this answer was succinct in a way that helped me understand more easily – StayCool Jul 9 '20 at 15:46
  • JigglyNagga Welcome to the meaning of TL;DR. Conciseness is also an important part of the information. This was the information which helped me and that is the reason I posted it to help people looking for a more condensed answer. Like I was. – mochomecha Jul 13 '20 at 23:05

How to find out.

# type .
. is a shell builtin

# help .
.: . filename [arguments]
    Execute commands from a file in the current shell.

    Read and execute commands from FILENAME in the current shell.  The
    entries in $PATH are used to find the directory containing FILENAME.
    If any ARGUMENTS are supplied, they become the positional parameters
    when FILENAME is executed.

    Exit Status:
    Returns the status of the last command executed in FILENAME; fails if
    FILENAME cannot be read.
  • I think there is a comma missing in the manual. It should say “Execute commands from a file, in the current shell.” – ctrl-alt-delor Jan 2 '19 at 11:33

. (source or dot operator)
Read and execute commands from the filename argument in the current shell context.

      . filename [arguments]

      source filename [arguments]

source is a synonym for dot/period '.' in bash, but not in POSIX sh, so for maximum compatibility use the period.

When a script is run using source it runs within the existing shell, any variables created or modified by the script will remain available after the script completes. In contrast if the script is run just as filename, then a separate subshell (with a completely separate set of variables) would be spawned to run the script.

There is a subtle difference between executing a script by running .ss64script (dot ss64script) and . ss64script (dot space ss64script)

the first is running a file thats been hidden from the 'ls' command, (although ls -a will show hidden files) the second option will execute ss64script even if it has not been set as an executable with chmod.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.