The Power Of A Dot In Linux Environment

Yes, there are several places where a dot (.) is being used in Linux terminal/Shell. In addition, a dot would depict some meaning when shown in the output of a command. Let us see the different places where we would normally use a dot and explore the other places where one could get to see this in Linux. The usage of a dot that is documented here is excluding the standard or regular use that is not specific to Linux/Unix and it is common across computer environments. Such as in representing a FQDN (Fully Qualified Domain Name) separated with dot, IP Address where each bit (from 0 to 255) is separated by a dot etc, 

 

[1] Used while navigating through directory structure using "cd" command. 

Yes, in a Linux terminal, one could use the "cd" command to navigate/move through the directory structure. The command "cd .." would move one directory level up, correspondingly the command "cd ../.." would move up 2 directories level, and so forth. 

Example:

  

As shown in the above example, the “pwd” command output shows the current working directory. So, the “cd” command could be used to navigate in the directory tree up to any level as required.

 

[2] Used to represent current directory when used along with commands such as "cp", "mv", "find" etc., 

A single dot (.) marks the current directory when used with commands as mentioned. Example: To copy all files from "/root/dir1" to the current directory, one could run the command "# cp /root/dir1/* .". Here the dot denotes the current working directory. 

As explained before, double dots could also be used to perform some operations on previous directory with supported commands: 

Example: The following command would copy file "file20" from parent directory to "/tmp" directory:

# cp ../file20 /tmp/

 

[3] To create a hidden file/directory. 

By prefixing a dot, any new directory/files could be created which are hidden from default file/directory listing. However, when used "ls -a" this would print out all files/directories including hidden data as shown below:

 

 

[4] In-line execution of a script. 

Whenever there is a requirement to call/execute a script without spawning a sub-shell, it could be executed in-line. When a script is executed in-line then all environment variables would also be available for a child script by default.

Let’s do a simple demonstration of this by creating a script which would print the shell Process ID when executed and the value of a variable called “TESTVAR”.  This variable is defined out of this shell script as shown below:

 

When the script is called as usual, it would spawn up another child shell and executes the command as shown below, and hence the value of the variable “TESTVAR” not showing anything:

 

However, when called in-line the shell would run with parent environment variables and settings. Hence, it would print the value of the “TESTVAR” and also notice the PID which is the PID of the current shell, not the sub-shell ($$ variable would print current shell PID): 

 

The same method is being used to source a file within a script. Either the command "source" could be used or call the file using the in-line execution mode (. ./filename). One good use case of this is when there is a separate file that contains all variable declarations that needs to be called inside a script. In that case, it is a general/best practice to source that file inside a script as required. 

 

[5] To create a range of new files/directories. 

One could create a range of files (new) required with a common name between the files. Lets see how it works: 

- Create range of new files with name test1,test2,test3....test10       

         # touch test{1..10}

- Create range of files with name file1,file3,file5....file20       

         # touch file{1..20..2}

Same way, even new directories could also be created as shown in below snap: 

 

[6] Used to specify a limited range of allowed hosts to have access in host-based control such as for NFS. 

A dot is used while defining the access range for NFS clients that is normally defined in the file "/etc/exports" file. This could be used while defining access/limit to all systems in one network as shown below:

/datafiles    172.18.1.(rw,no_root_squash)

Same way, one could limit/allow network range for supported services under host based control if required.

[7] A dot (bigger than normal size) is used to represent the status of a service which reflects whether it is active/failed/in-active in “systemctl” command. 

The dot ("●") uses color on supported terminals to summarize the unit state at a glance. White indicates an "inactive" or "deactivating" state. Red indicates a "failed" or "error" state and green indicates an "active", "reloading" or "activating" state.  

 

 

[8] A dot represents the SELinux context tags when shown as the output of “ll” or “ls -l” command.

The “ls -l” command does show if SELinux context tag is set or applicable on files/directories in the form of a dot at the end of permission bit list. Any new files/directories that are created when SELinux is disabled would not do this. To demonstrate this, let's disable SELinux and reboot the system, and then create a new file “newfile” and test it.

 

As it is noticed in the above snapshot, a new file and directory by name “newfile” & “newdir” are created after SELinux was disabled, and hence, the dot character just after the permission bit list is not there. However, enabling SELinux would kick-off the relabel process for all missing ones.