apostrophe

source/modify-hello-flake/main.adoc0

@@ -2,7 +2,7 @@
 
 == The Nix development shell
 
-Let’s make a simple modification to the script. This will give you an
+Let's make a simple modification to the script. This will give you an
 opportunity to check your understanding of flakes.
 
 The first step is to enter a development shell.
@@ -20,24 +20,24 @@ $ nix develop
 
 The `flake.nix` file specifies all of the tools that are needed during
 development of the package. The `nix develop` command puts us in a shell
-with those tools. As it turns out, we didn’t need any extra tools
-(beyond the standard environment) for development yet, but that’s
+with those tools. As it turns out, we didn't need any extra tools
+(beyond the standard environment) for development yet, but that's
 usually not the case. Also, we will soon need another tool.
 
 A development environment only allows you to _develop_ the package.
-Don’t expect the package _outputs_ (e.g. executables) to be available
-until you build them. However, our script doesn’t need to be compiled,
-so can’t we just run it?
+Don't expect the package _outputs_ (e.g. executables) to be available
+until you build them. However, our script doesn't need to be compiled,
+so can't we just run it?
 
 ....
 $ hello-flake
 ....
 
-That worked before; why isn’t it working now? Earlier we used
+That worked before; why isn't it working now? Earlier we used
 `nix shell` to enter a _runtime_ environment where `hello-flake` was
 available and on the `$PATH`. This time we entered a _development_
-environment using the `nix develop` command. Since the flake hasn’t been
-built yet, the executable won’t be on the `$PATH`. We can, however, run
+environment using the `nix develop` command. Since the flake hasn't been
+built yet, the executable won't be on the `$PATH`. We can, however, run
 it by specifying the path to the script.
 
 ....
@@ -52,14 +52,14 @@ $ nix build
 $ result/bin/hello-flake
 ....
 
-Rather than typing the full path to the executable, it’s more convenient
+Rather than typing the full path to the executable, it's more convenient
 to use `nix run`.
 
 ....
 $ nix run
 ....
 
-Here’s a summary of the more common Nix commands.
+Here's a summary of the more common Nix commands.
 
 [width="100%",cols="<17%,<83%",options="header",]
 |===
@@ -68,20 +68,20 @@ Here’s a summary of the more common Nix commands.
 development tools (e.g. compilers and linkers) available (as specified
 by `flake.nix`).
 
-|`nix shell` |Enters a _runtime_ shell where the flake’s executables are
+|`nix shell` |Enters a _runtime_ shell where the flake's executables are
 available on the `$PATH`.
 
 |`nix build` |Builds the flake and puts the output in a directory called
 `result`.
 
-|`nix run` |Runs the flake’s default executable, rebuilding the package
+|`nix run` |Runs the flake's default executable, rebuilding the package
 first if needed. Specifically, it runs the version in the Nix store, not
 the version in `result`.
 |===
 
 == Introducing a dependency
 
-Now we’re ready to make the flake a little more interesting.
+Now we're ready to make the flake a little more interesting.
 Instead of using the `echo` command in the script, we can use the Linux `cowsay`
 command.
 Here's the `hello-flake` file, with the modified line highlighted.
@@ -96,21 +96,21 @@ $ sed -i 's/echo/cowsay/' hello-flake
 $# cat hello-flake
 ....
 
-Let’s test the modified script.
+Let's test the modified script.
 
 ....
 $ ./hello-flake
 ....
 
 What went wrong? Remember that we are in a _development_ shell. Since
-`flake.nix` didn’t define the `devShells` variable, the development
+`flake.nix` didn't define the `devShells` variable, the development
 shell only includes the Nix standard environment. In particular, the
 `cowsay` command is not available.
 
 To fix the problem, we can modify `flake.nix`.
-We don’t need to add `cowsay` to the `inputs` section because it’s included in `nixpkgs`,
+We don't need to add `cowsay` to the `inputs` section because it's included in `nixpkgs`,
 which is already an input.
-However, we also want it to be available in a develoment shell.
+However, we also want it to be available in a development shell.
 The highlighted modifications below will accomplish that.
 
 ////
@@ -124,9 +124,9 @@ $# cat flake.nix
 ....
 
 Now we restart the development shell and see that the `cowsay` command is
-available and the script works. Because we’ve updated source files
-but haven’t ``git commit``ed the new version, we get a warning message
-about it being "`dirty`". It’s just a warning, though; the script runs
+available and the script works. Because we've updated source files
+but haven't ``git commit``ed the new version, we get a warning message
+about it being "`dirty`". It's just a warning, though; the script runs
 correctly.
 
 ....
@@ -144,7 +144,7 @@ $ nix run
 
 Note, however, that `nix run` rebuilt the package in the Nix store and
 ran _that_. It did not alter the copy in the `result` directory, as
-we’ll see next.
+we'll see next.
 
 ....
 $ cat result/bin/hello-flake
@@ -157,8 +157,8 @@ $ nix build
 $ cat result/bin/hello-flake
 ....
 
-Let’s `git commit` the changes and verify that the warning goes away. We
-don’t need to `git push` the changes until we’re ready to share them.
+Let's `git commit` the changes and verify that the warning goes away. We
+don't need to `git push` the changes until we're ready to share them.
 
 ....
 $ git commit hello-flake flake.nix -m 'added bovine feature'
@@ -167,8 +167,8 @@ $ nix run
 
 == Development workflows
 
-If you’re getting confused about when to use the different commands,
-it’s because there’s more than one way to use Nix. I tend to think of it
+If you're getting confused about when to use the different commands,
+it's because there's more than one way to use Nix. I tend to think of it
 as two different development workflows.
 
 My usual, _high-level workflow_ is quite simple.
@@ -178,14 +178,14 @@ My usual, _high-level workflow_ is quite simple.
 . Fix any problems in `flake.nix` or the source code.
 . Repeat until the package works properly.
 
-In the high-level workflow, I don’t use a development shell because I
-don’t need to directly invoke development tools such as compilers and
+In the high-level workflow, I don't use a development shell because I
+don't need to directly invoke development tools such as compilers and
 linkers. Nix invokes them for me according to the output definition in
 `flake.nix`.
 
 Occasionally I want to work at a lower level, and invoke compiler,
 linkers, etc. directly. Perhaps want to work on one component without
-rebuilding the entire package. Or perhaps I’m confused by some error
+rebuilding the entire package. Or perhaps I'm confused by some error
 message, so I want to temporarily bypass Nix and work directly with
 the compiler. In this case I temporarily switch to a _low-level
 workflow_.
@@ -196,12 +196,12 @@ I need (e.g. compilers, linkers, documentation generators).
 . Directly invoke tools such as compilers.
 . Fix any problems in `flake.nix` or the source code.
 . Directly invoke the executable. Note that the location of the
-executable depends on the development tools – It probably isn’t
+executable depends on the development tools – It probably isn't
 `result`!
 . Repeat until the package works properly.
 
 I generally only use `nix build` if I just want to build the package but
-not execute anything (perhaps it’s just a library).
+not execute anything (perhaps it's just a library).
 
 == This all seems like a hassle!