Login

Linux Tools: The Meaning of Dot

<div style="margin: 5px 5% 10px 5%;"><img src="http://www.sickgaming.net/blog/wp-content/uploads/2019/01/linux-tools-the-meaning-of-dot.jpg" width="1500" height="872" title="" alt="" /></div><div><div><img src="http://www.sickgaming.net/blog/wp-content/uploads/2019/01/linux-tools-the-meaning-of-dot.jpg" class="ff-og-image-inserted" /></div>
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.
<h3>Location, location, location</h3>
Take the humble dot (<code>.</code>) for example. Used with instructions that are expecting the name of a directory, it means “this directory” so this:
<pre>
find . -name "*.jpg"
</pre>
translates to “find in this directory (and all its subdirectories) files that have names that end in <code>.jpg</code>“.
Both <code>ls .</code> and <code>cd .</code> 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
<pre>
cd ..
</pre>
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:
<pre>
$ 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
</pre>
And then there’s when you use <code>.</code> as a command. Yep! You heard me: <code>.</code> is a full-fledged command. It is a synonym of <code>source</code> 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
<pre>
myvar="Hello"
</pre>
and execute it the regular way, that is, with <code>sh myscript</code> (or by making the script executable with <code>chmod a+x myscript</code> and then running <code>./myscript</code>). Now try and see the contents of <code>myvar</code> with <code>echo $myvar</code> (spoiler: You will get nothing). This is because, when your script plunks “Hello” into <code>myvar</code>, 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 <code>myvar</code> never even existed.
However, if you run myscript like this:
<pre>
. myscript
</pre>
<code>echo $myvar</code> will print Hello to the command line.
You will often use the <code>.</code> (or <code>source</code>) command after making changes to your .bashrc file, <a href="https://www.linux.com/blog/learn/2018/12/bash-variables-environmental-and-otherwise">like when you need to expand your <code>PATH</code> variable</a>. You use <code>.</code> to make the changes available immediately in your current shell instance.
<h3>Double Trouble</h3>
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 (<code>..</code>) is also used to build sequences.
Try this:
<pre>
echo {1..10}
</pre>
It will print out the list of numbers from 1 to 10. In this context, <code>..</code> means “starting with the value on my left, count up to the value on my right“.
Now try this:
<pre>
echo {1..10..2}
</pre>
You’ll get 1 3 5 7 9. The <code>..2</code> 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.
It works backwards, too:
<pre>
echo {10..1..2}
</pre>
You can also pad your numbers with 0s. Doing:
<pre>
echo {000..121..2}
</pre>
will print out every even number from 0 to 121 like this:
<pre>
000 002 004 006 ... 050 052 054 ... 116 118 120 </pre>
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:
<pre>
mkdir {2009..2019}_Invoices
</pre>
Job done.
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:
<pre>
rm frame_{043..61..3}
</pre>
It is likely that, if you have more than 100 frames, they will be named with padded 0s and look like this:
<pre>
frame_000 frame_001 frame_002 ...
</pre>
That’s why you will use <code>043</code> in your command instead of just <code>43</code>.
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 (<code>{}</code>). Look how it works for letters, too. Doing:
<pre>
touch file_{a..z}.txt
</pre>
creates the files file_a.txt through file_z.txt.
You must be careful, however. Using a sequence like <code>{Z..a}</code> 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 <code>{...}</code> is that they can also contain lists of strings:
<pre>
touch {blahg, splurg, mmmf}_file.txt
</pre>
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.
<h3>Conclusion</h3>
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.
Until then, have fun!
</div>

xSicKxBot