Don't use newlines inside backticks

spikefoo · spikefoo · commit 530e73cd284a · 2017-01-08T18:44:21.000+02:00
Line breaks inside backticks are preserved in output.
diff --git a/doc/GUIDE.md b/doc/GUIDE.md
@@ -16,8 +16,8 @@ Haskell tooling you need. This guide will follow that stack-centric approach.
 
 ### What makes stack special?
 
-The primary stack design point is __reproducible builds__. If you run `stack
-build` today, you should get the same result running `stack build` tomorrow.
+The primary stack design point is __reproducible builds__. If you run `stack build`
+today, you should get the same result running `stack build` tomorrow.
 There are some cases that can break that rule (changes in your operating system
 configuration, for example), but, overall, stack follows this design philosophy
 closely. To make this a simple process, stack uses curated package sets
@@ -1047,8 +1047,8 @@ project. To do that you can fix those versions by specifying them in the
 extra-deps section and then use `stack solver` to figure out whether it is
 feasible to use those or what other dependencies are needed as a result.
 
-If you want to change the resolver for your project, you can run `stack solver
---resolver <resolver name>` and it will figure out the changes needed for you.
+If you want to change the resolver for your project, you can run
+`stack solver --resolver <resolver name>` and it will figure out the changes needed for you.
 
 Let's see what happens if we change the resolver to lts-2.22:
 
@@ -1626,8 +1626,8 @@ a package as a *dependency package*.
 ## ghc/runghc
 
 You'll sometimes want to just compile (or run) a single Haskell source file,
-instead of creating an entire Cabal package for it. You can use `stack exec
-ghc` or `stack exec runghc` for that. As simple helpers, we also provide the
+instead of creating an entire Cabal package for it. You can use `stack exec ghc`
+or `stack exec runghc` for that. As simple helpers, we also provide the
 `stack ghc` and `stack runghc` commands, for these common cases.
 
 ## script interpreter
@@ -1759,8 +1759,8 @@ algorithm stack uses to find this is:
 The first two provide a convenient method for using an alternate configuration.
 For example: `stack build --stack-yaml stack-7.8.yaml` can be used by your CI
 system to check your code against GHC 7.8. Setting the `STACK_YAML` environment
-variable can be convenient if you're going to be running commands like `stack
-ghc` in other directories, but you want to use the configuration you defined in
+variable can be convenient if you're going to be running commands like `stack ghc`
+in other directories, but you want to use the configuration you defined in
 a specific project.
 
 If stack does not find a `stack.yaml` in any of the three specified locations,
@@ -1839,8 +1839,8 @@ Now the differences:
       packages. So for example, in stack, `stack test` does the same job as
       `cabal install --run-tests`, though the latter *additionally* performs an
       installation that you may not want. The closer command equivalent is
-      `cabal install --enable-tests --only-dependencies && cabal configure
-      --enable-tests && cabal build && cabal test` (newer versions of
+      `cabal install --enable-tests --only-dependencies && cabal configure --enable-tests && cabal build && cabal test`
+      (newer versions of
       cabal-install may make this command shorter).
 * __Isolated by default__.
     * This has been a pain point for new stack users. In cabal, the
diff --git a/doc/MAINTAINER_GUIDE.md b/doc/MAINTAINER_GUIDE.md
@@ -9,10 +9,10 @@
     * Update `stack-nightly.yaml` with latest nightly and remove extra-deps
     * Run `stack --stack-yaml=stack-nightly.yaml test`
 * Ensure integration tests pass on a representative Windows, macOS, and Linux (Linux
-  is handled by Jenkins automatically): `stack install --pedantic && stack test
-  --pedantic --flag stack:integration-tests` . The actual release script will
-  perform a more thorough test for every platform/variant prior to uploading, so
-  this is just a pre-check
+  is handled by Jenkins automatically):
+  `stack install --pedantic && stack test --pedantic --flag stack:integration-tests`.
+  The actual release script will perform a more thorough test for every platform/variant
+  prior to uploading, so this is just a pre-check
 * Ensure `stack haddock` works (Travis CI now does this)
 * Stack builds with `stack-7.8.yaml` (Travis CI now does this)
 * stack can build the wai repo
@@ -73,8 +73,8 @@ for requirements to perform the release, and more details about the tool.
 
 A note about the `etc/scripts/*-releases.sh` scripts: if you run them from a
 different working tree than the scripts themselves (e.g. if you have `stack1`
-and `stack2` trees, and run `cd stack1;
-../stack2/etc/scripts/vagrant-release.sh`) the scripts and Vagrantfiles from the
+and `stack2` trees, and run `cd stack1; ../stack2/etc/scripts/vagrant-release.sh`)
+the scripts and Vagrantfiles from the
 tree containing the script will be used to build the stack code in the current
 directory. That allows you to iterate on the release process while building a
 consistent and clean stack version.
@@ -110,8 +110,8 @@ consistent and clean stack version.
 * Build sdist using `stack sdist . --pvp-bounds=both`, and upload it to the
   Github release with a name like `stack-X.Y.Z-sdist-0.tar.gz`.
 
-* Publish Github release. Use e.g. `git shortlog -s v1.1.2..rc/v1.2.0|sed
-  's/^[0-9 ]*/* /'|sort -f` to get the list of contributors.
+* Publish Github release. Use e.g. `git shortlog -s v1.1.2..rc/v1.2.0|sed 's/^[0-9 ]*/* /'|sort -f`
+  to get the list of contributors.
 
 * Upload package to Hackage: `stack upload . --pvp-bounds=both`
 
@@ -126,11 +126,9 @@ consistent and clean stack version.
 
 * (SKIP) [Flag the Arch Linux package as out-of-date](https://www.archlinux.org/packages/community/x86_64/stack/flag/)
 
-* Push signed Git tag, matching Github release tag name, e.g.: `git tag -d vX.Y.Z; git tag -u
-  0x575159689BEFB442 vX.Y.Z && git push -f origin vX.Y.Z`
+* Push signed Git tag, matching Github release tag name, e.g.: `git tag -d vX.Y.Z; git tag -u 0x575159689BEFB442 vX.Y.Z && git push -f origin vX.Y.Z`
 
-* Reset the `release` branch to the released commit, e.g.: `git checkout release
-  && git merge --ff-only vX.Y.Z && git push origin release`
+* Reset the `release` branch to the released commit, e.g.: `git checkout release && git merge --ff-only vX.Y.Z && git push origin release`
 
 * Update the `stable` branch similarly
 
diff --git a/doc/build_command.md b/doc/build_command.md
@@ -22,8 +22,8 @@ synonyms in the `--help` output. These commands are:
 * `stack install` is the same as `stack build --copy-bins`
 
 The advantage of the synonym commands is that they're convenient and short. The
-advantage of the options is that they compose. For example, `stack build --test
---copy-bins` will build libraries, executables, and test suites, run the test
+advantage of the options is that they compose. For example, `stack build --test --copy-bins`
+will build libraries, executables, and test suites, run the test
 suites, and then copy the executables to your local bin path (more on this
 below).
 
@@ -56,8 +56,8 @@ benchmarks. If you want more control over a package, you must add it to your
 
 ## Target syntax
 
-In addition to a number of options (like the aforementioned `--test`), `stack
-build` takes a list of zero or more *targets* to be built. There are a number
+In addition to a number of options (like the aforementioned `--test`), `stack build`
+takes a list of zero or more *targets* to be built. There are a number
 of different syntaxes supported for this list:
 
 *   *package*, e.g. `stack build foobar`, is the most commonly used target. It
@@ -94,8 +94,7 @@ of different syntaxes supported for this list:
       have a component with the same name. To continue the above example,
       `stack build :mytestsuite`.
         * Side note: the commonly requested `run` command is not available
-          because it's a simple combination of `stack build :exename && stack
-          exec exename`
+          because it's a simple combination of `stack build :exename && stack exec exename`
 
 * *directory*, e.g. `stack build foo/bar`, will find all local packages that
   exist in the given directory hierarchy and then follow the same procedure as
@@ -106,8 +105,7 @@ of different syntaxes supported for this list:
 
 Finally: if you provide no targets (e.g., running `stack build`), stack will
 implicitly pass in all of your local packages. If you only want to target
-packages in the current directory or deeper, you can pass in `.`, e.g. `stack
-build .`.
+packages in the current directory or deeper, you can pass in `.`, e.g. `stack build .`.
 
 To get a list of the available targets in your project, use `stack ide targets`.
 
diff --git a/doc/coverage.md b/doc/coverage.md
@@ -22,8 +22,8 @@ When your project has these properties, you will get the following:
 2) A unified textual and HTML report, considering the coverage on all local
   libraries, based on all of the tests that were run.
 
-3) An index of all generated HTML reports, at `$(stack path
-   --local-hpc-root)/index.html`.
+3) An index of all generated HTML reports, at
+  `$(stack path --local-hpc-root)/index.html`.
 
 ## "stack hpc report" command
 
@@ -81,17 +81,17 @@ However, advanced users may want to understand exactly how `--coverage` works:
    When switching on this flag, it will usually cause all local packages to be
    rebuilt (see [#1940](https://github.com/commercialhaskell/stack/issues/1940).
 
-2. Before the build runs with `--coverage`, the contents of `stack path
-   --local-hpc-root` gets deleted. This prevents old reports from getting mixed
+2. Before the build runs with `--coverage`, the contents of `stack path --local-hpc-root`
+   gets deleted. This prevents old reports from getting mixed
    with new reports. If you want to preserve report information from multiple
    runs, copy the contents of this path to a new folder.
 
 3. Before a test run, if a `test-name.tix` file exists in the package directory,
    it will be deleted.
 
 4. After a test run, it will expect a `test-name.tix` file to exist. This file
-   will then get loaded, modified, and outputted to `$(stack path
-   --local-hpc-root)/pkg-name/test-name/test-name.tix)`.
+   will then get loaded, modified, and outputted to
+   `$(stack path --local-hpc-root)/pkg-name/test-name/test-name.tix)`.
 
    The `.tix` file gets modified to remove coverage file that isn't associated
    with a library. So, this means that you won't get coverage information for
@@ -107,14 +107,13 @@ However, advanced users may want to understand exactly how `--coverage` works:
 
 5. Once we have a `.tix` file for a test, we also generate a textual and HTML
    report for it. The textual report is sent to the terminal. The index of the
-   test-specific HTML report is available at `$(stack path
-   --local-hpc-root)/pkg-name/test-name/index.html`
+   test-specific HTML report is available at
+   `$(stack path --local-hpc-root)/pkg-name/test-name/index.html`
 
 6. After the build completes, if there are multiple output `*.tix` files, they
    get combined into a unified report. The index of this report will be
    available at `$(stack path --local-hpc-root)/combined/all/index.html`
 
 7. Finally, an index of the resulting coverage reports is generated. It links to
    the individual coverage reports (one for each test-suite), as well as the
-   unified report. This index is available at `$(stack path
-   --local-hpc-root)/index.html`
+   unified report. This index is available at `$(stack path --local-hpc-root)/index.html`
diff --git a/doc/docker_integration.md b/doc/docker_integration.md
@@ -137,8 +137,8 @@ behaviour.
 ### reset - Reset the Docker "sandbox"
 
 In order to preserve the contents of the in-container home directory between
-runs, a special "sandbox" directory is volume-mounted into the container. `stack
-docker reset` will reset that sandbox to its defaults.
+runs, a special "sandbox" directory is volume-mounted into the container.
+`stack docker reset` will reset that sandbox to its defaults.
 
 Note: `~/.stack` is separately volume-mounted, and is left alone during reset.
 
@@ -323,8 +323,8 @@ Additional notes
 ### Volume-mounts and ephemeral containers
 
 Since filesystem changes outside of the volume-mounted project directory are not
-persisted across runs, this means that if you `stack exec sudo apt-get install
-some-ubuntu-package`, that package will be installed but then the container it's
+persisted across runs, this means that if you `stack exec sudo apt-get install some-ubuntu-package`,
+that package will be installed but then the container it's
 installed in will disappear, thus causing it to have no effect. If you wish to
 make this kind of change permanent, see later instructions for how to create a
 [derivative Docker image](#derivative-image).
@@ -353,8 +353,8 @@ and publish port 3000.
 
 If you do want to do all your work, including editing, in the container, it
 might be better to use a persistent container in which you can install Ubuntu
-packages. You could get that by running something like `stack
---docker-container-name=NAME --docker-persist exec --plain bash`. This
+packages. You could get that by running something like
+`stack --docker-container-name=NAME --docker-persist exec --plain bash`. This
 means when the container exits, it won't be deleted. You can then restart it
 using `docker start -a -i NAME`. It's also possible to detach from a container
 while it continues running in the background using by pressing Ctrl-P Ctrl-Q,
@@ -419,8 +419,8 @@ Troubleshooting
 ### "No Space Left on Device", but 'df' shows plenty of disk space
 
 This is likely due to the storage driver Docker is using, in combination with
-the large size and number of files in these images. Use `docker info|grep
-'Storage Driver'` to determine the current storage driver.
+the large size and number of files in these images. Use `docker info|grep 'Storage Driver'`
+to determine the current storage driver.
 
 We recommend using either the `overlay` or `aufs` storage driver for stack, as
 they are least likely to give you trouble.  On Ubuntu, `aufs` is the default for
@@ -467,9 +467,8 @@ change to take effect:
 <small>
 The above commands turn off `dnsmasq` usage in NetworkManager
 configuration and restart network manager.  They can be reversed by executing
-`sudo sed 's@#dns=dnsmasq@dns=dnsmasq@' -i
-/etc/NetworkManager/NetworkManager.conf && sudo service network-manager
-restart`.  These instructions are adapted from
+`sudo sed 's@#dns=dnsmasq@dns=dnsmasq@' -i /etc/NetworkManager/NetworkManager.conf && sudo service network-manager restart`.
+These instructions are adapted from
 [the Shipyard Project's QuickStart guide](https://github.com/shipyard/shipyard/wiki/QuickStart#127011-dns-server-problem-on-ubuntu).
 </small>
 
diff --git a/doc/faq.md b/doc/faq.md
@@ -191,18 +191,17 @@ detailed discussion of stack's behavior when `system-ghc` is enabled.
 
 ## How do I upgrade to GHC 7.10.2 with stack?
 
-If you already have a prior version of GHC use `stack --resolver ghc-7.10 setup
---reinstall`. If you don't have any GHC installed, you can skip the
-`--reinstall`.
+If you already have a prior version of GHC use `stack --resolver ghc-7.10 setup --reinstall`.
+If you don't have any GHC installed, you can skip the `--reinstall`.
 
 ## How do I get extra build tools?
 
 stack will automatically install build tools required by your packages or their
 dependencies, in particular alex and happy.
 
 __NOTE__: This works when using lts or nightly resolvers, not with ghc or
-custom resolvers. You can manually install build tools by running, e.g., `stack
-build alex happy`.
+custom resolvers. You can manually install build tools by running, e.g.,
+`stack build alex happy`.
 
 ## How does stack choose which snapshot to use when creating a new config file?
 
@@ -418,8 +417,8 @@ If you manage to work around this in other distributions, please include instruc
 ## Where does the output from `--ghc-options=-ddump-splices` (and other `-ddump*` options) go?
 
 These are written to `*.dump-*` files inside the package's `.stack-work`
-directory. Specifically, they will be available at `PKG-DIR/$(stack path
---dist-dir)/build/SOURCE-PATH`, where `SOURCE-PATH` is the path to the source
+directory. Specifically, they will be available at
+`PKG-DIR/$(stack path --dist-dir)/build/SOURCE-PATH`, where `SOURCE-PATH` is the path to the source
 file, relative to the location of the `*.cabal` file. When building named
 components such as test-suites, `SOURCE-PATH` will also include
 `COMPONENT/COMPONENT-tmp`, where `COMPONENT` is the name of the component.
diff --git a/doc/ghcjs.md b/doc/ghcjs.md
@@ -9,9 +9,9 @@ To use GHCJS with stack, place a GHCJS version in the [`compiler`](yaml_configur
 You can also build existing stack projects which target GHC, and instead build
 them with GHCJS.  For example: `stack build --compiler ghcjs-0.2.0.9006020_ghc-7.10.3`
 
-Sidenote: If you receive a message like `The program 'ghcjs' version >=0.1 is
-required but the version of .../ghcjs could not be determined.`, then you may
-need to install a different version of `node`. See
+Sidenote: If you receive a message like
+`The program 'ghcjs' version >=0.1 is required but the version of .../ghcjs could not be determined.`,
+then you may need to install a different version of `node`. See
 [issue #1496](https://github.com/commercialhaskell/stack/issues/1496).
 
 ## Example Configurations
diff --git a/doc/nonstandard_project_init.md b/doc/nonstandard_project_init.md
@@ -36,8 +36,8 @@ flags:
     manual: true
 ```
 
-It is also possible to pass the same flag to multiple packages, i.e. `stack
-build --flag *:necessary`
+It is also possible to pass the same flag to multiple packages, i.e.
+`stack build --flag *:necessary`
 
 Currently one needs to list all of your modules that interpret flags in the
 `other-modules` section of a cabal file. `cabal-install` has a different
diff --git a/doc/yaml_configuration.md b/doc/yaml_configuration.md
@@ -206,8 +206,8 @@ Packages that come from the snapshot global database are not affected.
 
 ### image
 
-The image settings are used for the creation of container images using `stack
-image container`, e.g.
+The image settings are used for the creation of container images using
+`stack image container`, e.g.
 
 ```yaml
 image:
@@ -665,8 +665,8 @@ The 5 parameters are: `author-email`, `author-name`, `category`, `copyright` and
   name of the holder of the copyright on the package and the year(s) from which
   copyright is claimed. For example: `Copyright: (c) 2006-2007 Joe Bloggs`
 * _github-username_ - used to generate `homepage` and `source-repository` in
-  cabal. For instance `github-username: myusername` and `stack new my-project
-  new-template` would result:
+  cabal. For instance `github-username: myusername` and `stack new my-project new-template`
+  would result:
 
 ```yaml
 homepage: http://github.com/myusername/my-project#readme
