This explanation isn't correct, since a running `less` would not close the pipe and is still a reader. Writes to the pipe would block until `less` fully consumed it, or until `less` was quit such as with the `q` command.
The text _is_ correct if you add a missing step to `q`uit out of the `less` program. I think this step must have been dropped along the way. Unfortunately the screen capture doesn't show this step either.
The description of `seq` isn't even correct: "If a second argument is provided, the numbers will stop printing at the once the second number has been reached. Otherwise, the numbers will continue forever"
Nope, `seq`'s arguments are defined as `[first [incr]] last`. With a single argument, it counts up from 1 to `last`. Maybe some previous version of `seq` behaved differently, but not as far as I can recall.
But again, can't hold anything against the page given the disclaimer.