Since /dev/zero is clearly erroneous input, wouldn't it have been better if
it did report an error, instead of just accepting any old garbage?
It did - the only thing that makes /dev/zero invalid input for grep is
the fact that it requires (infinitely) more memory to store the first
line, than grep has available to it - and that's precisely the error
condition that grep reported, and I strongly suspect that it reported
that error condition shortly after finding out that it needed more space
than was available.
What validity test would you suggest that grep use? An arbitrary upper
line length of 1024 characters, rendering grep useless for someone who
needs to extract relevant lines from a file that contains some lines
longer than 1024 characters? Why impose a limit that doesn't need to be
Suppose the application in question does need to store entire lines at some
No one has ever advocated using character-at-a-time processing when
entire lines are needed, only when they are not needed (as is the case
for this thread).
Then the problems need to be solved (unless you suggest that no
program should *ever* use line-buffered input). Once they are solved, why
not use the same solution when reading Y or N?
For the same reason you don't add a full text editor to a program just
because it needs a line of input from the user. Or are you in the habit
of doing that? Just because you already have the text editor code
already written is no reason for inserting it into a program that
doesn't need it.