> If we pipe seq to less and look at the list of running processes using ps aux, we can see that the seq program is not running. ... This explains why the seq program is killed when it is piped to less.
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.
There's a big red disclaimer at the top of the page: "Ancient CS 61 Content Warning!!!!!1!!! This is not the current version of the class. This site was automatically translated from a wiki. The translation may have introduced mistakes (and the content might have been wrong to begin with)."
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.
Wouldn’t the seq process keep writing to output until the output buffer of the pipe got full and then the next write would block and seq would just pause waiting for the write call to unblock? Or my understanding of piping is incorrect?
The slide says something like "run the command `seq 2 10000000 | less` and check `ps`, notice that `seq` isn't running". But that isn't how the processes will behave, `seq` will continue running (albeit blocked) until `less` is dead or closes the pipe.
> If we pipe seq to less and look at the list of running processes using ps aux, we can see that the seq program is not running. ... This explains why the seq program is killed when it is piped to less.
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.
There's a big red disclaimer at the top of the page: "Ancient CS 61 Content Warning!!!!!1!!! This is not the current version of the class. This site was automatically translated from a wiki. The translation may have introduced mistakes (and the content might have been wrong to begin with)."
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.
Wouldn’t the seq process keep writing to output until the output buffer of the pipe got full and then the next write would block and seq would just pause waiting for the write call to unblock? Or my understanding of piping is incorrect?
What you've said is correct.
The slide says something like "run the command `seq 2 10000000 | less` and check `ps`, notice that `seq` isn't running". But that isn't how the processes will behave, `seq` will continue running (albeit blocked) until `less` is dead or closes the pipe.
Your understanding is correct. `seq` blocks when the pipe is full and is killed with SIGPIPE after `less` quits, closing the pipe.
Not "literative" programming, but "literate" programming. The official Knuth page: https://www-cs-faculty.stanford.edu/~knuth/lp.html
It also gets "Literate Programming" wrong, ironically.
Sadly this article is about programming and not suggestions for post-apocalyptic scenarios.
[flagged]