Turn exercise about number of path into regular text

diff --git a/Unix_Concepts.m4 b/Unix_Concepts.m4
index be51cc9096ad4af3e9bb5721e1bd67774f776be6..ab6cdbb0845fd74527fac7357a043fba66c6cff6 100644 (file)
--- a/Unix_Concepts.m4
+++ b/Unix_Concepts.m4
@@ -638,6 +638,24 @@ directory contains two subdirectories named <code>.</code> and
 <code>..</code> which refer to the directory itself and its parent
 directory, respectively. </p>
 
+<p> One consequence of the special meaning of the path components
+<code>.</code> and <code>..</code> is that there are infinitely
+many paths which refer to the same file. Indeed, given the path
+<code>/foo/bar</code>, one may construct different paths which
+refer to the same file by inserting any number of <code>/.</code>
+or <code>../foo</code> after the first component. For example,
+<code>/foo/./bar</code> and <code>/foo/../foo/bar</code> both refer
+to the same file. If relative paths have to be taken into account as
+well, even more paths can be constructed. </p>
+
+<p> This illustrates the fundamental difference between a path and a
+file. Paths can be mapped to files, but not the other way around. In
+particular, there is no such thing like "the list of paths which
+have changed since yesterday". Also, it is incorrect to assume
+that two files are different just because their paths are different.
+The concept of hard- and soft links discussed below further complicates
+the relationship between paths and files. </p>
+
 SUBSECTION(«Globbing»)
 
 <p> Globbing, also known as <em>pathname expansion</em>, is a pattern
@@ -663,7 +681,6 @@ the prompt. However, POSIX also demands system functions which make
 globbing available to other applications. These are implemented as
 part of libc. </p>
 
-
 <p> There are a few quirks related to globbing which are worth to
 point out. First, if no valid path matches the given pattern, the
 expansion of the pattern is, by definition according to POSIX, the
@@ -1005,6 +1022,27 @@ to traverse the whole hierarchy of files. This may be prohibitive
 for large filesystems, and the result is unreliable anyway unless
 the filesystems are mounted read-only. </p>
 
+<p> It is possible to choose among all possible paths which refer
+to the same file a <em>canonical</em> path, that is, a shortest
+(counting characters) absolute path which does not contain any soft
+links. In fact, the POSIX standard requires each Unix system library
+to provide the <code>realpath()</code> library function which performs
+the following substitutions on the given path: First, the path to
+the current working directory is prepended if the given path is
+relative (does not begin with a slash). Second, symbolic links are
+replaced by their targets. Third, any occurrences of <code>/.</code>
+and <code>foo/..</code> are removed. The thusly transformed path is
+returned by the function as the canonical path. </p>
+
+<p> Each path can be canonicalized in this way, but not all paths
+which refer to the same file give rise to the same canonical path. For
+example, <code>/tmp/foo</code> and <code>/tmp/bar</code> could refer
+to regular files which are hard links of each other. In this case the
+paths refer to the same file, yet the paths are different and already
+canonicalized. The same can happen when a file system (or a subtree
+of it) is <em>bind mounted</em>. That is, the file system tree is
+visible at two or more locations in the global directory tree. </p>
+
 EXERCISES()
 
 <ul>
@@ -1119,25 +1157,6 @@ EXERCISES()
        file type for hard links? </li>
 </ul>
 
-HOMEWORK(«
-How many paths are there that refer to the same file?
-», «
-Given the path <code>/foo/bar</code>, one may construct different paths
-which refer to the same file by inserting any number of <code>/.</code>
-or <code>../foo</code> after the first component. For example,
-<code>/foo/./bar</code> and <code>/foo/../foo/bar</code> both refer
-to the same file. If relative paths have to be taken into account as
-well, even more paths can be constructed easily. Hence the answer is:
-arbitrary many.
-
-This illustrates the fundamental difference between a path and a
-file. Paths can be mapped to files, but not the other way around. In
-particular, there is no such thing like "the list of paths which have
-changed since yesterday".
-
-The concept of hard- and soft links complicates the situation further.
-»)
-
 HOMEWORK(«
 Given two paths, how can one tell if they refer to the same file?
 », «
@@ -1305,38 +1324,6 @@ interpretations of <code>..</code> does bash apply when you type
 
 »)
 
-HOMEWORK(«
-
-Is it possible to choose among all possible paths which refer to the
-same file a <em>canonical</em> path? That is, a shortest (counting
-characters) absolute path which does not contain any soft links?
-
-», «
-
-<p> The POSIX standard requires each Unix system library to provide
-the <code>realpath()</code> function which performs the following
-substitutions on the given path: First, the path to the current
-working directory is prepended if the given path is relative
-(does not begin with a slash). Second, symbolic links are replaced
-by their targets. Third, any occurrences of <code>/.</code> and
-<code>foo/..</code> are removed. The thusly transformed path is
-returned by the function as the canonical path. </p>
-
-<p> Although each path can be canonicalized in this way, not all paths
-which refer to the same file give rise to the same canonical path. For
-example, <code>/tmp/foo</code> and <code>/tmp/bar</code> could refer
-to regular files which are hard links of each other. In this case the
-paths refer to the same file, yet the paths are different and already
-canonicalized. The same can happen when a file system (or a subtree
-of it) is <em>bind mounted</em>. That is, the file system tree is
-visible at two or more locations in the global directory tree. </p>
-
-The message of this exercise is to convince the reader that it is
-incorrect to assume that two files are different because their paths
-are different.
-
-»)
-
 SECTION(«Processes»)
 
 <p> A <em>program</em> consists of instructions and data stored in