Merge pull request #207150 from ncfavier/doc-minor

doc/builders/images/ocitools.section.md

@@ -34,4 +34,4 @@ buildContainer {
 
 - `mounts` specifies additional mount points chosen by the user. By default only a minimal set of necessary filesystems are mounted into the container (e.g procfs, cgroupfs)
 
-- `readonly` makes the container\'s rootfs read-only if it is set to true. The default value is false `false`.
+- `readonly` makes the container's rootfs read-only if it is set to true. The default value is false `false`.

doc/builders/packages/dlib.section.md

@@ -4,7 +4,7 @@
 
 ## Compiling without AVX support {#compiling-without-avx-support}
 
-Especially older CPUs don\'t support [AVX](https://en.wikipedia.org/wiki/Advanced_Vector_Extensions) (Advanced Vector Extensions) instructions that are used by DLib to optimize their algorithms.
+Especially older CPUs don't support [AVX](https://en.wikipedia.org/wiki/Advanced_Vector_Extensions) (Advanced Vector Extensions) instructions that are used by DLib to optimize their algorithms.
 
 On the affected hardware errors like `Illegal instruction` will occur. In those cases AVX support needs to be disabled:
 

doc/contributing/submitting-changes.chapter.md

@@ -199,7 +199,7 @@ It’s important to test any executables generated by a build when you change or
 
 ### Meets Nixpkgs contribution standards {#submitting-changes-contribution-standards}
 
-The last checkbox is fits [CONTRIBUTING.md](https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md). The contributing document has detailed information on standards the Nix community has for commit messages, reviews, licensing of contributions you make to the project, etc\... Everyone should read and understand the standards the community has for contributing before submitting a pull request.
+The last checkbox is fits [CONTRIBUTING.md](https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md). The contributing document has detailed information on standards the Nix community has for commit messages, reviews, licensing of contributions you make to the project, etc... Everyone should read and understand the standards the community has for contributing before submitting a pull request.
 
 ## Hotfixing pull requests {#submitting-changes-hotfixing-pull-requests}
 

doc/functions/nix-gitignore.section.md

@@ -4,7 +4,7 @@
 
 ## Usage {#sec-pkgs-nix-gitignore-usage}
 
-`pkgs.nix-gitignore` exports a number of functions, but you\'ll most likely need either `gitignoreSource` or `gitignoreSourcePure`. As their first argument, they both accept either 1. a file with gitignore lines or 2. a string with gitignore lines, or 3. a list of either of the two. They will be concatenated into a single big string.
+`pkgs.nix-gitignore` exports a number of functions, but you'll most likely need either `gitignoreSource` or `gitignoreSourcePure`. As their first argument, they both accept either 1. a file with gitignore lines or 2. a string with gitignore lines, or 3. a list of either of the two. They will be concatenated into a single big string.
 
 ```nix
 { pkgs ? import <nixpkgs> {} }:
@@ -30,7 +30,7 @@ gitignoreSourcePure = gitignoreFilterSourcePure (_: _: true);
 gitignoreSource = gitignoreFilterSource (_: _: true);
 ```
 
-Those filter functions accept the same arguments the `builtins.filterSource` function would pass to its filters, thus `fn: gitignoreFilterSourcePure fn ""` should be extensionally equivalent to `filterSource`. The file is blacklisted if it\'s blacklisted by either your filter or the gitignoreFilter.
+Those filter functions accept the same arguments the `builtins.filterSource` function would pass to its filters, thus `fn: gitignoreFilterSourcePure fn ""` should be extensionally equivalent to `filterSource`. The file is blacklisted if it's blacklisted by either your filter or the gitignoreFilter.
 
 If you want to make your own filter from scratch, you may use
 

doc/using/configuration.chapter.md

@@ -73,7 +73,7 @@ There are also two ways to try compiling a package which has been marked as unsu
     }
     ```
 
-The difference between a package being unsupported on some system and being broken is admittedly a bit fuzzy. If a program *ought* to work on a certain platform, but doesn't, the platform should be included in `meta.platforms`, but marked as broken with e.g.  `meta.broken = !hostPlatform.isWindows`. Of course, this begs the question of what \"ought\" means exactly. That is left to the package maintainer.
+The difference between a package being unsupported on some system and being broken is admittedly a bit fuzzy. If a program *ought* to work on a certain platform, but doesn't, the platform should be included in `meta.platforms`, but marked as broken with e.g.  `meta.broken = !hostPlatform.isWindows`. Of course, this begs the question of what "ought" means exactly. That is left to the package maintainer.
 
 ## Installing unfree packages {#sec-allow-unfree}
 

nixos/doc/manual/administration/service-mgmt.chapter.md

@@ -75,7 +75,7 @@ necessary).
 
 Packages in Nixpkgs sometimes provide systemd units with them, usually
 in e.g `#pkg-out#/lib/systemd/`. Putting such a package in
-`environment.systemPackages` doesn\'t make the service available to
+`environment.systemPackages` doesn't make the service available to
 users or the system.
 
 In order to enable a systemd *system* service with provided upstream
@@ -87,9 +87,9 @@ systemd.packages = [ pkgs.packagekit ];
 
 Usually NixOS modules written by the community do the above, plus take
 care of other details. If a module was written for a service you are
-interested in, you\'d probably need only to use
+interested in, you'd probably need only to use
 `services.#name#.enable = true;`. These services are defined in
-Nixpkgs\' [ `nixos/modules/` directory
+Nixpkgs' [ `nixos/modules/` directory
 ](https://github.com/NixOS/nixpkgs/tree/master/nixos/modules). In case
 the service is simple enough, the above method should work, and start
 the service on boot.
@@ -98,8 +98,8 @@ the service on boot.
 differently. Given a package that has a systemd unit file at
 `#pkg-out#/lib/systemd/user/`, using [](#opt-systemd.packages) will
 make you able to start the service via `systemctl --user start`, but it
-won\'t start automatically on login. However, You can imperatively
-enable it by adding the package\'s attribute to
+won't start automatically on login. However, You can imperatively
+enable it by adding the package's attribute to
 [](#opt-systemd.packages) and then do this (e.g):
 
 ```ShellSession
@@ -113,7 +113,7 @@ If you are interested in a timer file, use `timers.target.wants` instead
 of `default.target.wants` in the 1st and 2nd command.
 
 Using `systemctl --user enable syncthing.service` instead of the above,
-will work, but it\'ll use the absolute path of `syncthing.service` for
+will work, but it'll use the absolute path of `syncthing.service` for
 the symlink, and this path is in `/nix/store/.../lib/systemd/user/`.
 Hence [garbage collection](#sec-nix-gc) will remove that file and you
 will wind up with a broken symlink in your systemd configuration, which

nixos/doc/manual/configuration/kubernetes.chapter.md

@@ -17,7 +17,7 @@ services.kubernetes = {
 };
 ```
 
-Another way is to assign cluster roles (\"master\" and/or \"node\") to
+Another way is to assign cluster roles ("master" and/or "node") to
 the host. This enables apiserver, controllerManager, scheduler,
 addonManager, kube-proxy and etcd:
 

nixos/doc/manual/configuration/profiles.chapter.md

@@ -2,7 +2,7 @@
 
 In some cases, it may be desirable to take advantage of commonly-used,
 predefined configurations provided by nixpkgs, but different from those
-that come as default. This is a role fulfilled by NixOS\'s Profiles,
+that come as default. This is a role fulfilled by NixOS's Profiles,
 which come as files living in `<nixpkgs/nixos/modules/profiles>`. That
 is to say, expected usage is to add them to the imports list of your
 `/etc/configuration.nix` as such:

nixos/doc/manual/configuration/user-mgmt.chapter.md

@@ -30,7 +30,7 @@ to your NixOS configuration. For instance, if you remove a user from
 [](#opt-users.users) and run nixos-rebuild, the user
 account will cease to exist. Also, imperative commands for managing users and
 groups, such as useradd, are no longer available. Passwords may still be
-assigned by setting the user\'s
+assigned by setting the user's
 [hashedPassword](#opt-users.users._name_.hashedPassword) option. A
 hashed password can be generated using `mkpasswd`.
 

nixos/doc/manual/configuration/wayland.chapter.md

@@ -4,7 +4,7 @@ While X11 (see [](#sec-x11)) is still the primary display technology
 on NixOS, Wayland support is steadily improving. Where X11 separates the
 X Server and the window manager, on Wayland those are combined: a
 Wayland Compositor is like an X11 window manager, but also embeds the
-Wayland \'Server\' functionality. This means it is sufficient to install
+Wayland 'Server' functionality. This means it is sufficient to install
 a Wayland Compositor such as sway without separately enabling a Wayland
 server:
 

nixos/doc/manual/configuration/x-windows.chapter.md

@@ -81,7 +81,7 @@ second password to login can be redundant.
 
 To enable auto-login, you need to define your default window manager and
 desktop environment. If you wanted no desktop environment and i3 as your
-your window manager, you\'d define:
+your window manager, you'd define:
 
 ```nix
 services.xserver.displayManager.defaultSession = "none+i3";
@@ -110,7 +110,7 @@ maintained but may perform worse in some cases (like in old chipsets).
 
 The second driver, `intel`, is specific to Intel GPUs, but not
 recommended by most distributions: it lacks several modern features (for
-example, it doesn\'t support Glamor) and the package hasn\'t been
+example, it doesn't support Glamor) and the package hasn't been
 officially updated since 2015.
 
 The results vary depending on the hardware, so you may have to try both
@@ -162,7 +162,7 @@ with other kernel modules.
 
 AMD provides a proprietary driver for its graphics cards that is not
 enabled by default because it's not Free Software, is often broken in
-nixpkgs and as of this writing doesn\'t offer more features or
+nixpkgs and as of this writing doesn't offer more features or
 performance. If you still want to use it anyway, you need to explicitly
 set:
 
@@ -215,7 +215,7 @@ US layout, with an additional layer to type some greek symbols by
 pressing the right-alt key.
 
 Create a file called `us-greek` with the following content (under a
-directory called `symbols`; it\'s an XKB peculiarity that will help with
+directory called `symbols`; it's an XKB peculiarity that will help with
 testing):
 
 ```nix
@@ -249,7 +249,7 @@ The name (after `extraLayouts.`) should match the one given to the
 
 Applying this customization requires rebuilding several packages, and a
 broken XKB file can lead to the X session crashing at login. Therefore,
-you\'re strongly advised to **test your layout before applying it**:
+you're strongly advised to **test your layout before applying it**:
 
 ```ShellSession
 $ nix-shell -p xorg.xkbcomp
@@ -313,8 +313,8 @@ prefer to keep the layout definitions inside the NixOS configuration.
 
 Unfortunately, the Xorg server does not (currently) support setting a
 keymap directly but relies instead on XKB rules to select the matching
-components (keycodes, types, \...) of a layout. This means that
-components other than symbols won\'t be loaded by default. As a
+components (keycodes, types, ...) of a layout. This means that
+components other than symbols won't be loaded by default. As a
 workaround, you can set the keymap using `setxkbmap` at the start of the
 session with:
 
@@ -323,7 +323,7 @@ services.xserver.displayManager.sessionCommands = "setxkbmap -keycodes media";
 ```
 
 If you are manually starting the X server, you should set the argument
-`-xkbdir /etc/X11/xkb`, otherwise X won\'t find your layout files. For
+`-xkbdir /etc/X11/xkb`, otherwise X won't find your layout files. For
 example with `xinit` run
 
 ```ShellSession

nixos/doc/manual/configuration/xfce.chapter.md

@@ -31,8 +31,8 @@ enabled. To enable Thunar without enabling Xfce, use the configuration
 option [](#opt-programs.thunar.enable) instead of simply adding
 `pkgs.xfce.thunar` to [](#opt-environment.systemPackages).
 
-If you\'d like to add extra plugins to Thunar, add them to
-[](#opt-programs.thunar.plugins). You shouldn\'t just add them to
+If you'd like to add extra plugins to Thunar, add them to
+[](#opt-programs.thunar.plugins). You shouldn't just add them to
 [](#opt-environment.systemPackages).
 
 ## Troubleshooting {#sec-xfce-troubleshooting .unnumbered}
@@ -46,7 +46,7 @@ Thunar:2410): GVFS-RemoteVolumeMonitor-WARNING **: remote volume monitor with db
 ```
 
 This is caused by some needed GNOME services not running. This is all
-fixed by enabling \"Launch GNOME services on startup\" in the Advanced
+fixed by enabling "Launch GNOME services on startup" in the Advanced
 tab of the Session and Startup settings panel. Alternatively, you can
 run this command to do the same thing.
 

nixos/doc/manual/development/option-declarations.section.md

@@ -149,7 +149,7 @@ multiple modules, or as an alternative to related `enable` options.
 
 As an example, we will take the case of display managers. There is a
 central display manager module for generic display manager options and a
-module file per display manager backend (sddm, gdm \...).
+module file per display manager backend (sddm, gdm ...).
 
 There are two approaches we could take with this module structure:
 

nixos/doc/manual/development/option-types.section.md

@@ -92,11 +92,11 @@ merging is handled.
 :   A free-form attribute set.
 
     ::: {.warning}
-    This type will be deprecated in the future because it doesn\'t
+    This type will be deprecated in the future because it doesn't
     recurse into attribute sets, silently drops earlier attribute
-    definitions, and doesn\'t discharge `lib.mkDefault`, `lib.mkIf`
+    definitions, and doesn't discharge `lib.mkDefault`, `lib.mkIf`
     and co. For allowing arbitrary attribute sets, prefer
-    `types.attrsOf types.anything` instead which doesn\'t have these
+    `types.attrsOf types.anything` instead which doesn't have these
     problems.
     :::
 
@@ -222,7 +222,7 @@ Submodules are detailed in [Submodule](#section-option-types-submodule).
     -   *`specialArgs`* An attribute set of extra arguments to be passed
         to the module functions. The option `_module.args` should be
         used instead for most arguments since it allows overriding.
-        *`specialArgs`* should only be used for arguments that can\'t go
+        *`specialArgs`* should only be used for arguments that can't go
         through the module fixed-point, because of infinite recursion or
         other problems. An example is overriding the `lib` argument,
         because `lib` itself is used to define `_module.args`, which
@@ -236,7 +236,7 @@ Submodules are detailed in [Submodule](#section-option-types-submodule).
         In such a case it would allow the option to be set with
         `the-submodule.config = "value"` instead of requiring
         `the-submodule.config.config = "value"`. This is because
-        only when modules *don\'t* set the `config` or `options`
+        only when modules *don't* set the `config` or `options`
         keys, all keys are interpreted as option definitions in the
         `config` section. Enabling this option implicitly puts all
         attributes in the `config` section.
@@ -324,7 +324,7 @@ Composed types are types that take a type as parameter. `listOf
 :   Type *`t1`* or type *`t2`*, e.g. `with types; either int str`.
     Multiple definitions cannot be merged.
 
-`types.oneOf` \[ *`t1 t2`* \... \]
+`types.oneOf` \[ *`t1 t2`* ... \]
 
 :   Type *`t1`* or type *`t2`* and so forth, e.g.
     `with types; oneOf [ int str bool ]`. Multiple definitions cannot be

nixos/doc/manual/development/replace-modules.section.md

@@ -2,7 +2,7 @@
 
 Modules that are imported can also be disabled. The option declarations,
 config implementation and the imports of a disabled module will be
-ignored, allowing another to take it\'s place. This can be used to
+ignored, allowing another to take its place. This can be used to
 import a set of modules from another channel while keeping the rest of
 the system on a stable release.
 
@@ -14,7 +14,7 @@ relative to the modules path (eg. \<nixpkgs/nixos/modules> for nixos).
 This example will replace the existing postgresql module with the
 version defined in the nixos-unstable channel while keeping the rest of
 the modules and packages from the original nixos channel. This only
-overrides the module definition, this won\'t use postgresql from
+overrides the module definition, this won't use postgresql from
 nixos-unstable unless explicitly configured to do so.
 
 ```nix
@@ -35,7 +35,7 @@ nixos-unstable unless explicitly configured to do so.
 
 This example shows how to define a custom module as a replacement for an
 existing module. Importing this module will disable the original module
-without having to know it\'s implementation details.
+without having to know its implementation details.
 
 ```nix
 { config, lib, pkgs, ... }:

nixos/doc/manual/development/settings-options.section.md

@@ -9,10 +9,10 @@ can be declared. File formats can be separated into two categories:
     `{ foo = { bar = 10; }; }`. Other examples are INI, YAML and TOML.
     The following section explains the convention for these settings.
 
--   Non-nix-representable ones: These can\'t be trivially mapped to a
+-   Non-nix-representable ones: These can't be trivially mapped to a
     subset of Nix syntax. Most generic programming languages are in this
     group, e.g. bash, since the statement `if true; then echo hi; fi`
-    doesn\'t have a trivial representation in Nix.
+    doesn't have a trivial representation in Nix.
 
     Currently there are no fixed conventions for these, but it is common
     to have a `configFile` option for setting the configuration file
@@ -24,7 +24,7 @@ can be declared. File formats can be separated into two categories:
     an `extraConfig` option of type `lines` to allow arbitrary text
     after the autogenerated part of the file.
 
-## Nix-representable Formats (JSON, YAML, TOML, INI, \...) {#sec-settings-nix-representable}
+## Nix-representable Formats (JSON, YAML, TOML, INI, ...) {#sec-settings-nix-representable}
 
 By convention, formats like this are handled with a generic `settings`
 option, representing the full program configuration as a Nix value. The

nixos/doc/manual/development/writing-documentation.chapter.md

@@ -19,7 +19,7 @@ $ nix-shell
 nix-shell$ make
 ```
 
-Once you are done making modifications to the manual, it\'s important to
+Once you are done making modifications to the manual, it's important to
 build it before committing. You can do that as follows:
 
 ```ShellSession

nixos/doc/manual/development/writing-modules.chapter.md

@@ -71,7 +71,7 @@ The meaning of each part is as follows.
 -   This `imports` list enumerates the paths to other NixOS modules that
     should be included in the evaluation of the system configuration. A
     default set of modules is defined in the file `modules/module-list.nix`.
-    These don\'t need to be added in the import list.
+    These don't need to be added in the import list.
 
 -   The attribute `options` is a nested set of *option declarations*
     (described below).

nixos/doc/manual/development/writing-nixos-tests.section.md

@@ -165,7 +165,7 @@ The following methods are available on machine objects:
 `get_screen_text_variants`
 
 :   Return a list of different interpretations of what is currently
-    visible on the machine\'s screen using optical character
+    visible on the machine's screen using optical character
     recognition. The number and order of the interpretations is not
     specified and is subject to change, but if no exception is raised at
     least one will be returned.
@@ -177,7 +177,7 @@ The following methods are available on machine objects:
 `get_screen_text`
 
 :   Return a textual representation of what is currently visible on the
-    machine\'s screen using optical character recognition.
+    machine's screen using optical character recognition.
 
     ::: {.note}
     This requires [`enableOCR`](#test-opt-enableOCR) to be set to `true`.
@@ -350,8 +350,8 @@ machine.wait_for_unit("xautolock.service", "x-session-user")
 This applies to `systemctl`, `get_unit_info`, `wait_for_unit`,
 `start_job` and `stop_job`.
 
-For faster dev cycles it\'s also possible to disable the code-linters
-(this shouldn\'t be committed though):
+For faster dev cycles it's also possible to disable the code-linters
+(this shouldn't be committed though):
 
 ```nix
 {
@@ -370,7 +370,7 @@ For faster dev cycles it\'s also possible to disable the code-linters
 
 This will produce a Nix warning at evaluation time. To fully disable the
 linter, wrap the test script in comment directives to disable the Black
-linter directly (again, don\'t commit this within the Nixpkgs
+linter directly (again, don't commit this within the Nixpkgs
 repository):
 
 ```nix