What’s the meaning of a dot before a command in shell?
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.
Example
Say I had the following contents in a sample.sh file.
$ cat sample.sh echo "hi" echo "bye?" Files such as this are often used to incorporate setup commands such as adding things to ones environment variables.
Examples
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.
Now when I source this file:
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 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:
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
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:
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.
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.
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.
Welcome to U&L! This answer duplicates information that’s already in the accepted answer, and doesn’t really add anything.
with respect, although technically Jiggly is correct — this answer was succinct in a way that helped me understand more easily
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.
. (source or dot operator)
Read and execute commands from the filename argument in the current shell context.
Syntax . 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.
Linux Tools: The Meaning of Dot
Let’s face it: writing one-liners and scripts using shell commands can be confusing. Many of the names of the tools at your disposal are far from obvious in terms of what they do (grep, tee and awk, anyone?) and, when you combine two or more, the resulting “sentence” looks like some kind of alien gobbledygook.
None of the above is helped by the fact that many of the symbols you use to build a chain of instructions can mean different things depending on their context.
Location, location, location
Take the humble dot ( . ) for example. Used with instructions that are expecting the name of a directory, it means “this directory” so this:
translates to “find in this directory (and all its subdirectories) files that have names that end in .jpg “.
Both ls . and cd . act as expected, so they list and “change” to the current directory, respectively, although including the dot in these two cases is not necessary.
Two dots, one after the other, in the same context (i.e., when your instruction is expecting a directory path) means “the directory immediately above the current one“. If you are in /home/your_directory and run
you will be taken to /home. So, you may think this still kind of fits into the “dots represent nearby directories” narrative and is not complicated at all, right?
How about this, then? If you use a dot at the beginning of a directory or file, it means the directory or file will be hidden:
$ touch somedir/file01.txt somedir/file02.txt somedir/.secretfile.txt $ ls -l somedir/ total 0 -rw-r--r-- 1 paul paul 0 Jan 13 19:57 file01.txt -rw-r--r-- 1 paul paul 0 Jan 13 19:57 file02.txt $ # Note how there is no .secretfile.txt in the listing above $ ls -la somedir/ total 8 drwxr-xr-x 2 paul paul 4096 Jan 13 19:57 . drwx------ 48 paul paul 4096 Jan 13 19:57 .. -rw-r--r-- 1 paul paul 0 Jan 13 19:57 file01.txt -rw-r--r-- 1 paul paul 0 Jan 13 19:57 file02.txt -rw-r--r-- 1 paul paul 0 Jan 13 19:57 .secretfile.txt $ # The -a option tells ls to show "all" files, including the hidden ones
And then there’s when you use . as a command. Yep! You heard me: . is a full-fledged command. It is a synonym of source and you use that to execute a file in the current shell, as opposed to running a script some other way (which usually mean Bash will spawn a new shell in which to run it).
Confused? Don’t worry — try this: Create a script called myscript that contains the line
and execute it the regular way, that is, with sh myscript (or by making the script executable with chmod a+x myscript and then running ./myscript ). Now try and see the contents of myvar with echo $myvar (spoiler: You will get nothing). This is because, when your script plunks “Hello” into myvar , it does so in a separate bash shell instance. When the script ends, the spawned instance disappears and control returns to the original shell, where myvar never even existed.
However, if you run myscript like this:
echo $myvar will print Hello to the command line.
You will often use the . (or source ) command after making changes to your .bashrc file, like when you need to expand your PATH variable. You use . to make the changes available immediately in your current shell instance.
Double Trouble
Just like the seemingly insignificant single dot has more than one meaning, so has the double dot. Apart from pointing to the parent of the current directory, the double dot ( .. ) is also used to build sequences.
It will print out the list of numbers from 1 to 10. In this context, .. means “starting with the value on my left, count up to the value on my right“.
You’ll get 1 3 5 7 9. The ..2 part of the command tells Bash to print the sequence, but not one by one, but two by two. In other words, you’ll get all the odd numbers from 1 to 10.
You can also pad your numbers with 0s. Doing:
will print out every even number from 0 to 121 like this:
000 002 004 006 . 050 052 054 . 116 118 120
But how is this sequence-generating construct useful? Well, suppose one of your New Year’s resolutions is to be more careful with your accounts. As part of that, you want to create directories in which to classify your digital invoices of the last 10 years:
Or maybe you have a hundreds of numbered files, say, frames extracted from a video clip, and, for whatever reason, you want to remove only every third frame between the frames 43 and 61:
It is likely that, if you have more than 100 frames, they will be named with padded 0s and look like this:
frame_000 frame_001 frame_002 .
That’s why you will use 043 in your command instead of just 43 .
Curly~Wurly
Truth be told, the magic of sequences lies not so much in the double dot as in the sorcery of the curly braces ( <> ). Look how it works for letters, too. Doing:
creates the files file_a.txt through file_z.txt.
You must be careful, however. Using a sequence like will run through a bunch of non-alphanumeric characters (glyphs that are neither numbers or letters) that live between the uppercase alphabet and the lowercase one. Some of these glyphs are unprintable or have a special meaning of their own. Using them to generate names of files could lead to a whole bevy of unexpected and potentially unpleasant effects.
One final thing worth pointing out about sequences encased between <. >is that they can also contain lists of strings:
Creates blahg_file.txt, splurg_file.txt and mmmf_file.txt.
Of course, in other contexts, the curly braces have different meanings (surprise!). But that is the stuff of another article.
Conclusion
Bash and the utilities you can run within it have been shaped over decades by system administrators looking for ways to solve very particular problems. To say that sysadmins and their ways are their own breed of special would be an understatement. Consequently, as opposed to other languages, Bash was not designed to be user-friendly, easy or even logical.
That doesn’t mean it is not powerful — quite the contrary. Bash’s grammar and shell tools may be inconsistent and sprawling, but they also provide a dizzying range of ways to do everything you can possibly imagine. It is like having a toolbox where you can find everything from a power drill to a spoon, as well as a rubber duck, a roll of duct tape, and some nail clippers.
Apart from fascinating, it is also fun to discover all you can achieve directly from within the shell, so next time we will delve ever deeper into how you can build bigger and better Bash command lines.
In bash, what does dot command ampersand do?
I’m trying to understand a bash script I’m supposed to be maintaining and got stuck. The command is of this form:
. $APP_LOCATION/somescript.sh param1 param2 & The line is not being called in a loop, not is any return code bening sent back to the calling script from somescript.sh I know that the «.» will make the process run in the same shell. But «&» will spawn off a different process. That sounds contradictory. What’s is really happening here? Any ideas?
2 Answers 2
The script is running in a background process, but it is a subshell, not a separately-invoked interpreter as it would be without the dot.
That is to say — the current interpreter forks and then begins running the command (sourcing the script). As such, it inherits shell variables, not just environment variables.
Otherwise the new script’s interpreter would be invoked via an execv() call, which would replace the current interpreter with a new one. That’s usually the right thing, because it provides more flexibility — you can’t run anything but a script written for the same shell with . or source , after all, whereas starting a new interpreter means that your other script could be rewritten in Python, Perl, a compiled binary, etc without its callers needing to change.
(This is part of why scripts intended to be exec’d, as opposed to than libraries meant to be sourced, should not have filename extensions — and part of why bash libraries should be .bash , not .sh , such that inaccurate information isn’t provided about what kind of interpreter they can be sourced into).