Merge pull request #12618 from fzakaria/minor-text-fixes

Fix minor documentation typos

Author: Mic92

doc/manual/source/store/derivation/outputs/index.md

@@ -1,15 +1,15 @@
 # Derivation Outputs and Types of Derivations
 
 As stated on the [main pages on derivations](../index.md#store-derivation),
-a derivation produces [store objects], which are known as the *outputs* of the derivation.
+a derivation produces [store objects](@docroot@/store/store-object.md), which are known as the *outputs* of the derivation.
 Indeed, the entire point of derivations is to produce these outputs, and to reliably and reproducably produce these derivations each time the derivation is run.
 
 One of the parts of a derivation is its *outputs specification*, which specifies certain information about the outputs the derivation produces when run.
 The outputs specification is a map, from names to specifications for individual outputs.
 
 ## Output Names {#outputs}
 
-Output names can be any string which is also a valid [store path] name.
+Output names can be any string which is also a valid [store path](@docroot@/store/store-path.md) name.
 The name mapped to each output specification is not actually the name of the output.
 In the general case, the output store object has name `derivationName + "-" + outputSpecName`, not any other metadata about it.
 However, an output spec named "out" describes and output store object whose name is just the derivation name.
@@ -24,11 +24,11 @@ However, an output spec named "out" describes and output store object whose name
 >
 > - The store path of `dev` will be: `/nix/store/<hash>-hello-dev`.
 
-The outputs are the derivations are the [store objects][store object] it is obligated to produce.
+The outputs are the derivations are the [store objects](@docroot@/store/store-object.md) it is obligated to produce.
 
 > **Note**
 >
-> The formal terminology here is somewhat at adds with everyday communication in the Nix community today.
+> The formal terminology here is somewhat at odds with everyday communication in the Nix community today.
 > "output" in casual usage tends to refer to either to the actual output store object, or the notional output spec, depending on context.
 >
 > For example "hello's `dev` output" means the store object referred to by the store path `/nix/store/<hash>-hello-dev`.
@@ -64,7 +64,7 @@ The rules for this are fairly concise:
 
     (This is an arbitrary restriction that could be lifted.)
 
-- The output is either *fixed* or *floating*, indicating whether the its store path is known prior to building it.
+- The output is either *fixed* or *floating*, indicating whether the store path is known prior to building it.
 
   - With fixed content-addressing it is fixed.
 

doc/manual/source/store/file-system-object/content-address.md

@@ -46,7 +46,7 @@ be many different serialisations.
 For these reasons, Nix has its very own archive format—the Nix Archive (NAR) format,
 which is carefully designed to avoid the problems described above.
 
-The exact specification of the Nix Archive format is in `protocols/nix-archive.md`
+The exact specification of the Nix Archive format is in [specified here](../../protocols/nix-archive.md).
 
 ## Content addressing File System Objects beyond a single serialisation pass
 
@@ -80,6 +80,7 @@ Thus, Git can encode some, but not all of Nix's "File System Objects", and this
 
 In the future, we may support a Git-like hash for such file system objects, or we may adopt another Merkle DAG format which is capable of representing all Nix file system objects.
 
+
 [file system object]: ../file-system-object.md
 [store object]: ../store-object.md
 [xp-feature-git-hashing]: @docroot@/development/experimental-features.md#xp-feature-git-hashing

doc/manual/source/store/store-object/content-address.md

@@ -50,7 +50,7 @@ The hashes of these modified input streams are used instead.
 
 When validating the content address of a store object after the fact, the above process works as written.
 However, when first creating the store object we don't know the store object's store path, as explained just above.
-We therefore, strictly speaking, do not know what value we will be replacing with the sentinental value in the inputs to hash functions.
+We therefore, strictly speaking, do not know what value we will be replacing with the sentinel value in the inputs to hash functions.
 What instead happens is that the provisional store object --- the data from which we wish to create a store object --- is paired with a provisional "scratch" store path (that presumably was chosen when the data was created).
 That provisional store path is instead what is replaced with the sentinel value, rather than the final store object which we do not yet know.