As you continue learning Bash, you'll eventually come across a command that looks almost too simple to be useful:
.
Just a single dot.
At first glance, it doesn't look like much. In fact, many beginners mistake it for punctuation or assume it has something to do with the current directory (./). While the two are related, they are not the same thing.
The . command (also known as the dot command) is one of the most powerful built-in commands in Bash. It allows you to read and execute another file inside the current shell session, instead of starting a new one.
This seemingly small difference has huge implications. It affects variables, functions, environment settings, the current working directory, and even the behavior of your terminal after the script finishes.
In this article, we'll explore exactly how the dot command works, when you should use it, how it differs from executing a script normally, and why it's the foundation of reusable Bash libraries.
What Does the Dot Command Do?
The general syntax is very simple:
. filename
or
. /path/to/file
When Bash encounters this command, it:
- Opens the specified file.
- Reads it line by line.
- Executes everything inside the current shell.
Unlike running a script normally, Bash does not create a new shell process.
Everything happens in the shell you're already using.
The Long Form: source
Most modern Bash users actually write:
source filename
The source command is simply a more readable synonym for ..
These two commands are identical:
source settings.sh
and
. settings.sh
Both execute the file in the current shell.
Personally, I often use source because it's more descriptive, but you'll encounter the dot command everywhere, from Linux tutorials to system startup scripts, so it's important to understand both forms.
Why Not Just Run the Script?
Suppose we have this script:
#!/bin/bash
MY_VAR="Hello"
Save it as:
config.sh
Now execute it normally:
./config.sh
Nothing appears to happen.
Now check:
echo "$MY_VAR"
Output:
The variable doesn't exist.
Why?
Because executing a script normally launches a new shell process.
That process creates the variable.
Then the process exits.
Everything inside it disappears.
Running the Same Script with .
Now try:
. ./config.sh
or
source ./config.sh
Then:
echo "$MY_VAR"
Output:
Hello
This time the variable still exists.
Why?
Because the script executed inside your current shell.
Nothing was isolated.
This Is the Biggest Difference
Let's compare the two approaches.
Normal execution
./script.sh
- Starts a new shell
- Runs the script
- Exits
- Variables disappear
- Functions disappear
- Directory changes disappear
Dot command
. script.sh
- Uses the current shell
- No new process
- Variables remain
- Functions remain
- Environment remains
- Directory changes remain
That last point surprises many beginners.
Changing Directories
Suppose we have:
#!/bin/bash
cd /tmp
If we execute:
./move.sh
and then run:
pwd
we'll still be in our original directory.
The script changed its own working directory, not ours.
Now try:
. ./move.sh
Then:
pwd
Output:
/tmp
Now your shell has actually changed directories.
That's because the script executed inside your current session.
Loading Environment Variables
One of the most common uses of the dot command is loading configuration files.
Example:
# config.sh
DATABASE_HOST=localhost
DATABASE_PORT=5432
DATABASE_USER=admin
Then:
source config.sh
Now all three variables become available:
echo "$DATABASE_HOST"
echo "$DATABASE_PORT"
echo "$DATABASE_USER"
This is much cleaner than defining everything manually.
Loading Functions
Another extremely common use is sharing functions between scripts.
Suppose we have:
# utilities.sh
say_hello()
{
echo "Hello!"
}
goodbye()
{
echo "Goodbye!"
}
Now another script can load these functions:
#!/bin/bash
source utilities.sh
say_hello
goodbye
Output:
Hello!
Goodbye!
This allows you to build reusable Bash libraries instead of copying the same code into every script.
We'll cover this technique in much more detail later when we discuss writing reusable Bash function libraries.
Does the File Need to Be Executable?
One interesting feature of the dot command is that the file does not need executable permissions.
For example:
chmod -x config.sh
Normally:
./config.sh
would fail with:
Permission denied
However:
source config.sh
still works perfectly.
Why?
Because Bash isn't executing the file as a program.
It's simply reading it as text.
What About the Shebang?
Consider this file:
#!/bin/bash
echo "Hello"
When executed normally:
./script.sh
the operating system reads:
#!/bin/bash
to determine which interpreter should execute the file.
However, when using:
source script.sh
or
. script.sh
the shebang is effectively ignored.
The commands are interpreted by the shell that is already running, regardless of which interpreter is specified on the first line.
This is another reason configuration files often don't include a shebang at all—they aren't meant to be executed directly.
Where Can Bash Find the File?
You can source a file in several ways.
Current directory:
source ./config.sh
Absolute path:
source /home/john/scripts/config.sh
Relative path:
source ../shared/functions.sh
Or, if the file is located in one of the directories listed in your $PATH, you can simply write:
source filename
A Practical Example
Let's create two files.
First:
# colors.sh
RED="\e[31m"
GREEN="\e[32m"
RESET="\e[0m"
Second:
#!/bin/bash
source colors.sh
echo -e "${GREEN}Everything works!${RESET}"
Instead of redefining colors in every script, we store them in one file and reuse them everywhere.
This keeps our code cleaner and easier to maintain.
Common Beginner Mistakes
One of the most common mistakes is confusing:
.
with
./
These are completely different.
The dot command:
. script.sh
means:
Read this file and execute it in the current shell.
Meanwhile:
./script.sh
means:
Execute the file located in the current directory.
They may look similar, but they behave very differently.
Another common mistake is expecting variables created by a normally executed script to remain available afterwards.
They won't.
If you want variables, functions, aliases, or directory changes to persist, use source or the dot command instead.
Best Practices
Here are a few recommendations when using the dot command:
- Use
sourcewhen readability is more important than brevity. - Use the dot command in scripts where compact syntax is preferred.
- Store shared functions in separate files.
- Store configuration values separately from your application logic.
- Remember that sourced scripts modify your current shell, so only source files that you trust.
- Avoid sourcing scripts that perform destructive actions unless that is exactly what you intend.
Looking Ahead
The dot command becomes incredibly powerful when combined with Bash functions. Instead of writing the same helper functions in every script, you can place them in a shared library and load them whenever you need them.
Later in this series we'll build our own Bash function library and use the dot command to import it into multiple scripts, making our code cleaner, shorter, and much easier to maintain.
Conclusion
The . command may be one of the shortest commands in Bash, but it's also one of the most useful. By executing a file inside the current shell instead of launching a new one, it allows variables, functions, aliases, and environment changes to remain available after the file finishes.
Whether you're loading configuration files, importing reusable functions, or customizing your shell environment, understanding the dot command is an essential step toward writing professional Bash scripts.
Although many developers prefer the more descriptive source command today, both forms are identical. Once you understand how they work, you'll begin to notice them everywhere—from Linux startup files like .bashrc to advanced automation scripts and deployment tools.
For more about creating reusable Bash functions, read my other post: Bash Functions Explained: The name() Function Syntax, where we'll start building our own Bash function libraries.