Linux basics from the founder of Gentoo. Part 1 (3/4): Links, and deleting files and directories

The third excerpt from the translation of the first part of the manual. Previous: first , second .

This excerpt covers hard and symbolic links, and also deals with deleting files and directories using the rm and rmdir commands.

Creating links and deleting files

Hard links

We already mentioned the term “link” when we talked about the relationship between directories (their names) and inodes (index numbers underlying the file system, which we do not notice). In general, there are two types of links in Linux. The type we mentioned earlier is called “hard links.” Each inode can have an arbitrary number of hard links. When the last hard link is destroyed, and not one program keeps the file open, Linux automatically deletes it. New hard links can be created using the ln command:

 $ cd /tmp 
 $ touch firstlink 
 $ ln firstlink secondlink 
 $ ls -i firstlink secondlink 
 15782 firstlink 15782 secondlink 

As you can see, hard links work at the inode level to specify a specific file. On Linux systems, for hard links there are several limitations. In particular, you can create hard links only to files, not to directories. Yes Yes exactly; although "." and ".." are hard links created by the system to directories, you (even on behalf of the user "root") are not allowed to create any of your own. The second limitation of hard links is that you cannot link several file systems with them. This means that you will not be able to create a hard link from / usr / bin / bash to / bin / bash and if your directories / and / usr are in different file systems (sections - approx. Lane).

')

Symbolic links

In practice, symbolic links (or symbolic, sometimes “symlinks” - from English) are used more often than hard links. Simlinks are special files that refer to other files by name, and not directly by the inode number. They do not save files from being deleted; if the file to which the link points disappears, then the symlink stops working, breaks.

Symbolic links can be created by passing the -s option for ln.

 $ ln -s secondlink thirdlink 
 $ ls -l firstlink secondlink thirdlink 
 -rw-rw-r-- 2 agriffis agriffis 0 Dec 31 19:08 firstlink -rw-rw-r-- 2 agriffis agriffis 0 Dec 31 19:08 secondlink lrwxrwxrwx 1 agriffis agriffis 10 Dec 31 19:39 thirdlink -> secondlink 

In the output of ls -l, symbolic links can be distinguished in three ways. First, notice the l character in the first column. Secondly, the size of the symbolic link is equal to the number of characters in it ( second link in our case). Thirdly, the last column in the output shows where the link leads by the intuitive notation "->".

Simlinki in detail

Symbolic links are generally more flexible than hard links. You can create symbolic links to any file system object, including directories. And due to the fact that their implementation is based on paths (not inodes), it is completely free to create a symbolic link pointing to an object in another file system. However, this fact also makes them difficult to understand.

Suppose we want to create a link in / tmp that points to / usr / local / bin . We should type:

 $ ln -s /usr/local/bin bin1 
 $ ls -l bin1 
 lrwxrwxrwx 1 root root 14 Jan 1 15:42 bin1 -> /usr/local/bin 

Or alternatively:

 $ ln -s ../usr/local/bin bin2 
 $ ls -l bin2 
 lrwxrwxrwx 1 root root 16 Jan 1 15:43 bin2 -> ../usr/local/bin 

As you can see, both symbolic links point to the same directory. However, if our second symbolic link is ever moved to another directory, then it may break due to the relativity of the path:

 $ ls -l bin2 
 lrwxrwxrwx 1 root root 16 Jan 1 15:43 bin2 -> ../usr/local/bin 
 $ mkdir mynewdir 
 $ mv bin2 mynewdir 
 $ cd mynewdir 
 $ cd bin2 
 bash: cd: bin2: No such file or directory 

$ ls -l bin2
lrwxrwxrwx 1 root root 16 Jan 1 15:43 bin2 -> ../usr/local/bin
$ mkdir mynewdir
$ mv bin2 mynewdir
$ cd mynewdir
$ cd bin2
bash: cd: bin2: No such file or directory

Because the / tmp / usr / local / bin directory does not exist, we can no longer move to bin2 ; in other words, bin2 is now broken.

For this reason, avoiding creating links with relative path information will sometimes be a good idea. However, there are many cases where relative symbolic links are extremely convenient. Consider an example in which we want to create an alternative name for a program in / usr / bin :

 # ls -l /usr/bin/keychain 
 -rwxr-xr-x 1 root root 10150 Dec 12 20:09 /usr/bin/keychain 

On behalf of the superuser, we want a short synonym for keychain , such as kc . In this example, we have root access, as evidenced by the bash greeting changed to "#". We need root access because normal users do not have permissions to create files in / usr / bin . On behalf of the superuser, we can create an alternate name for keychain as follows:

 # cd /usr/bin 
 # ln -s /usr/bin/keychain kc 
 # ls -l keychain 
 -rwxr-xr-x 1 root root 10150 Dec 12 20:09 /usr/bin/keychain 
 # ls -l kc 
 lrwxrwxrwx 1 root root 17 Mar 27 17:44 kc -> /usr/bin/keychain 

# cd /usr/bin
# ln -s /usr/bin/keychain kc
# ls -l keychain
-rwxr-xr-x 1 root root 10150 Dec 12 20:09 /usr/bin/keychain
# ls -l kc
lrwxrwxrwx 1 root root 17 Mar 27 17:44 kc -> /usr/bin/keychain

 # cd /usr/bin 
 # ln -s /usr/bin/keychain kc 
 # ls -l keychain 
 -rwxr-xr-x 1 root root 10150 Dec 12 20:09 /usr/bin/keychain 
 # ls -l kc 
 lrwxrwxrwx 1 root root 17 Mar 27 17:44 kc -> /usr/bin/keychain 

In this example, we created a symbolic link called kc, which points to the / usr / bin / keychain file.

For now, this solution will work, but will create a problem if we decide to move both files, / usr / bin / keychain and / usr / bin / kc to / usr / local / bin :

 # mv /usr/bin/keychain /usr/bin/kc /usr/local/bin 
 # ls -l /usr/local/bin/keychain 
 -rwxr-xr-x 1 root root 10150 Dec 12 20:09 /usr/local/bin/keychain 
 # ls -l /usr/local/bin/kc 
 lrwxrwxrwx 1 root root 17 Mar 27 17:44 kc -> /usr/bin/keychain 

# mv /usr/bin/keychain /usr/bin/kc /usr/local/bin
# ls -l /usr/local/bin/keychain
-rwxr-xr-x 1 root root 10150 Dec 12 20:09 /usr/local/bin/keychain
# ls -l /usr/local/bin/kc
lrwxrwxrwx 1 root root 17 Mar 27 17:44 kc -> /usr/bin/keychain

 # mv /usr/bin/keychain /usr/bin/kc /usr/local/bin 
 # ls -l /usr/local/bin/keychain 
 -rwxr-xr-x 1 root root 10150 Dec 12 20:09 /usr/local/bin/keychain 
 # ls -l /usr/local/bin/kc 
 lrwxrwxrwx 1 root root 17 Mar 27 17:44 kc -> /usr/bin/keychain 

Since we used the absolute path for the kc symbolic link, it still refers to / usr / bin / keychain , which has not existed since we moved / usr / bin / keychain to / usr / local / bin .

This led to the fact that the kc symlink is not working now. Both relative and absolute paths in symbolic links have advantages, and, depending on your task, you need to use the appropriate type of path. Often, both the relative and absolute paths will work equally well. The example below will work, even after moving both files:

 # cd /usr/bin 
 # ln -s keychain kc 
 # ls -l kc 
 lrwxrwxrwx 1 root root 8 Jan 5 12:40 kc -> keychain 
 # mv keychain kc /usr/local/bin 
 # ls -l /usr/local/bin/keychain 
 -rwxr-xr-x 1 root root 10150 Dec 12 20:09 /usr/local/bin/keychain 
 # ls -l /usr/local/bin/kc 
 lrwxrwxrwx 1 root root 17 Mar 27 17:44 kc -> keychain 

# cd /usr/bin
# ln -s keychain kc
# ls -l kc
lrwxrwxrwx 1 root root 8 Jan 5 12:40 kc -> keychain
# mv keychain kc /usr/local/bin
# ls -l /usr/local/bin/keychain
-rwxr-xr-x 1 root root 10150 Dec 12 20:09 /usr/local/bin/keychain
# ls -l /usr/local/bin/kc
lrwxrwxrwx 1 root root 17 Mar 27 17:44 kc -> keychain

 # cd /usr/bin 
 # ln -s keychain kc 
 # ls -l kc 
 lrwxrwxrwx 1 root root 8 Jan 5 12:40 kc -> keychain 
 # mv keychain kc /usr/local/bin 
 # ls -l /usr/local/bin/keychain 
 -rwxr-xr-x 1 root root 10150 Dec 12 20:09 /usr/local/bin/keychain 
 # ls -l /usr/local/bin/kc 
 lrwxrwxrwx 1 root root 17 Mar 27 17:44 kc -> keychain 

# cd /usr/bin
# ln -s keychain kc
# ls -l kc
lrwxrwxrwx 1 root root 8 Jan 5 12:40 kc -> keychain
# mv keychain kc /usr/local/bin
# ls -l /usr/local/bin/keychain
-rwxr-xr-x 1 root root 10150 Dec 12 20:09 /usr/local/bin/keychain
# ls -l /usr/local/bin/kc
lrwxrwxrwx 1 root root 17 Mar 27 17:44 kc -> keychain

 # cd /usr/bin 
 # ln -s keychain kc 
 # ls -l kc 
 lrwxrwxrwx 1 root root 8 Jan 5 12:40 kc -> keychain 
 # mv keychain kc /usr/local/bin 
 # ls -l /usr/local/bin/keychain 
 -rwxr-xr-x 1 root root 10150 Dec 12 20:09 /usr/local/bin/keychain 
 # ls -l /usr/local/bin/kc 
 lrwxrwxrwx 1 root root 17 Mar 27 17:44 kc -> keychain 

Now, we can start the keychain program by typing / usr / local / bin / kc . / usr / local / bin / kc points to the keychain program in the same directory where kc is located.

rm

So, we know how to use cp, mv and ln, it's time to learn how to delete objects from the file system. This is usually done with the rm command. To delete files, simply specify them on the command line:

 $ cd /tmp 
 $ touch file1 file2 
 $ ls -l file1 file2 
 -rw-r--r-- 1 root root 0 Jan 1 16:41 file1 -rw-r--r-- 1 root root 0 Jan 1 16:41 file2 
 $ rm file1 file2 
 $ ls -l file1 file2 
 ls: file1: No such file or directory 
 ls: file2: No such file or directory 

$ cd /tmp
$ touch file1 file2
$ ls -l file1 file2
-rw-r--r-- 1 root root 0 Jan 1 16:41 file1 -rw-r--r-- 1 root root 0 Jan 1 16:41 file2
$ rm file1 file2
$ ls -l file1 file2
ls: file1: No such file or directory
ls: file2: No such file or directory

Keep in mind that under Linux, once a deleted file, it usually disappears forever. Therefore, many novice system administrators use the -i option when deleting files. The -i option tells rm to delete files online — this means asking before deleting any file. For example:

$ rm -i file1 file2
rm: remove regular empty file `file1'? y
rm: remove regular empty file `file2'? y

In the example above, the rm command requests confirmation to delete each of the specified files. In case of agreement, I had to enter "y" and press enter, twice. If I entered "n", then the file would remain intact. Or, if I did something wrong, I could press Control-C and reset the entire rm -i command — all before it could do any damage to my system.

If you are still learning to use the rm command, it may be useful to add the following line to your ~ / .bashrc file with your favorite text editor, and then log out and log in again. After that, whenever you type rm, the bash shell automatically converts it to the rm -i command. Thus, rm will always work interactively:

alias rm="rm -i"

rmdir

You have two options for deleting directories. You can delete all objects within the directory and then use rmdir to delete the directory itself:

$ mkdir mydir
$ touch mydir/file1
$ rm mydir/file1
$ rmdir mydir

This method is commonly known as the “method of deleting directories for suckers”. All real boys and guru admins who have eaten a dog user in this case use the much more convenient rm -rf command, described below.

The best way to remove a directory is to use the “recursive force” options of the rm command to order it to delete the specified directory, as well as the objects contained within:

$ rm -rf mydir

Usually, rm -rf is the preferred method to remove the directory tree. Be very careful when using rm -rf, since its power can be used on both sides: good and evil. =)

Continued ...

---

About the authors

Daniel Robbins

Daniel Robbins is the founder of the Gentoo community and the creator of the Gentoo Linux operating system. Daniel lives in New Mexico with his wife, Mary, and two energetic daughters. He is also the founder and head of Funtoo , has written many technical articles for IBM developerWorks , Intel Developer Services and the C / C ++ Users Journal.

Chris Houser

Chris Hauser was a UNIX supporter since 1994 when he joined the team of administrators at Taylor University (Indiana, USA), where he received a bachelor's degree in computer science and mathematics. After that, he worked in many areas, including web applications, video editing, drivers for UNIX, and cryptographic protection. Currently working in Sentry Data Systems. Chris also contributed to many free projects, such as Gentoo Linux and Clojure, co-authored The Joy of Clojure .

Aron griffis

Airon Griffis lives in Boston, where he spent the last decade working with Hewlett-Packard on projects such as UNIX network drivers for Tru64, Linux security certification, Xen and KVM virtualization, and most recently, the HP ePrint platform. In his spare time, Airon prefers to ponder over the problems of programming while riding his bike, juggling bits, or cheering on the Boston Red Baseball team.