Merge pull request #27434 from danix800/fix-doc-typos

Fix typos in docs/reference/builder.md.

docs/extend/index.md

@@ -36,7 +36,7 @@ Hub or on a private registry.
 
 You install the plugin using a single command: `docker plugin install <PLUGIN>`.
 The `plugin install` command pulls the plugin from the Docker Hub or private
-registry. If necessary the CLI prompts you to accept any privilige requriements.
+registry. If necessary the CLI prompts you to accept any privilege requriements.
 For example the plugin may require access to a device on the host system.
 Finally it enables the plugin.
 
@@ -63,7 +63,7 @@ to create a volume.
     The plugin requests 2 privileges, the `CAP_SYS_ADMIN` capability to be able
     to do mount inside the plugin and `host networking`.
 
-2. Check for a value of `true` the `ENABLED` column to verify the plugin
+2.  Check for a value of `true` the `ENABLED` column to verify the plugin
 started without error.
 
     ```bash
@@ -73,7 +73,7 @@ started without error.
     vieux/sshfs         latest              true
     ```
 
-3. Create a volume using the plugin.
+3.  Create a volume using the plugin.
 
     ```bash
     $ docker volume create \
@@ -92,7 +92,7 @@ started without error.
     <content of /remote on machine 1.2.3.4>
     ```
 
-5. Verify the plugin successfully created the volume.
+5.  Verify the plugin successfully created the volume.
 
     ```bash
     $ docker volume ls

docs/extend/plugin_api.md

@@ -121,6 +121,7 @@ ExecStart=/usr/lib/docker/your-plugin
 WantedBy=multi-user.target
 ```
 The `socket` file (for example `/lib/systemd/system/your-plugin.socket`):
+
 ```
 [Unit]
 Description=Your plugin

docs/reference/builder.md

@@ -21,7 +21,7 @@ Practices](../userguide/eng-image/dockerfile_best-practices.md) for a tip-orient
 The [`docker build`](commandline/build.md) command builds an image from
 a `Dockerfile` and a *context*. The build's context is the files at a specified
 location `PATH` or `URL`. The `PATH` is a directory on your local filesystem.
-The `URL` is a the location of a Git repository.
+The `URL` is a Git repository location.
 
 A context is processed recursively. So, a `PATH` includes any subdirectories and
 the `URL` includes the repository and its submodules. A simple build command
@@ -504,7 +504,7 @@ default is `/bin/sh -c` on Linux or `cmd /S /C` on Windows)
 - `RUN ["executable", "param1", "param2"]` (*exec* form)
 
 The `RUN` instruction will execute any commands in a new layer on top of the
-current image and commit the results. The resulting comitted image will be
+current image and commit the results. The resulting committed image will be
 used for the next step in the `Dockerfile`.
 
 Layering `RUN` instructions and generating commits conforms to the core
@@ -519,13 +519,15 @@ command.
 
 In the *shell* form you can use a `\` (backslash) to continue a single
 RUN instruction onto the next line. For example, consider these two lines:
+
 ```
-RUN /bin/bash -c 'source $HOME/.bashrc ;\
+RUN /bin/bash -c 'source $HOME/.bashrc; \
 echo $HOME'
 ```
 Together they are equivalent to this single line:
+
 ```
-RUN /bin/bash -c 'source $HOME/.bashrc ; echo $HOME'
+RUN /bin/bash -c 'source $HOME/.bashrc; echo $HOME'
 ```
 
 > **Note**:
@@ -641,7 +643,7 @@ If the user specifies arguments to `docker run` then they will override the
 default specified in `CMD`.
 
 > **Note**:
-> don't confuse `RUN` with `CMD`. `RUN` actually runs a command and commits
+> Don't confuse `RUN` with `CMD`. `RUN` actually runs a command and commits
 > the result; `CMD` does not execute anything at build time, but specifies
 > the intended command for the image.
 
@@ -751,7 +753,7 @@ and
     ENV myDog Rex The Dog
     ENV myCat fluffy
 
-will yield the same net results in the final container, but the first form
+will yield the same net results in the final image, but the first form
 is preferred because it produces a single cache layer.
 
 The environment variables set using `ENV` will persist when a container is run
@@ -773,7 +775,7 @@ ADD has two forms:
 whitespace)
 
 The `ADD` instruction copies new files, directories or remote file URLs from `<src>`
-and adds them to the filesystem of the container at the path `<dest>`.
+and adds them to the filesystem of the image at the path `<dest>`.
 
 Multiple `<src>` resource may be specified but if they are files or
 directories then they must be relative to the source directory that is
@@ -806,7 +808,7 @@ of whether or not the file has changed and the cache should be updated.
 > can only contain a URL based `ADD` instruction. You can also pass a
 > compressed archive through STDIN: (`docker build - < archive.tar.gz`),
 > the `Dockerfile` at the root of the archive and the rest of the
-> archive will get used at the context of the build.
+> archive will be used as the context of the build.
 
 > **Note**:
 > If your URL files are protected using authentication, you
@@ -848,7 +850,7 @@ guide](../userguide/eng-image/dockerfile_best-practices.md#build-cache) for more
 - If `<src>` is a *local* tar archive in a recognized compression format
   (identity, gzip, bzip2 or xz) then it is unpacked as a directory. Resources
   from *remote* URLs are **not** decompressed. When a directory is copied or
-  unpacked, it has the same behavior as `tar -x`: the result is the union of:
+  unpacked, it has the same behavior as `tar -x`, the result is the union of:
 
     1. Whatever existed at the destination path and
     2. The contents of the source tree, with conflicts resolved in favor
@@ -1677,7 +1679,7 @@ a shell operates. For example, using `SHELL cmd /S /C /V:ON|OFF` on Windows, del
 environment variable expansion semantics could be modified.
 
 The `SHELL` instruction can also be used on Linux should an alternate shell be
-required such `zsh`, `csh`, `tcsh` and others.
+required such as `zsh`, `csh`, `tcsh` and others.
 
 The `SHELL` feature was added in Docker 1.12.