On 8/20/21 8:25 AM, Paul Eggert wrote:
(Not that anyone would ever want to *use* plain "grep -f -", except
perhaps to file bug reports)
I discovered a more-artificial case where grep messes up even on modern
platforms, namely 'grep -f - -f -' where grep essentially ignores the
second '-f
I'd guess you're seeing some of the design decisions in stdio,
that were rather "controversial", back around Version 7 Unix,
inside Bell Labs, circa late 1978, when stdio was first introduced.
I've avoided using fread(3S) "forever", even to the point of rolling
my own i/o buffering library, the mo
Nope! It looks like a behavior of fread.
We have to reverse the middle two arguments of fread,
so that it's reading an n-sized array of 1-byte objects,
rather than one object of size n.
#include
int main(void)
{
char buf[8192];
while (fread(buf, 1, sizeof buf, stdin) != 0);
Please allow me to add a semi-final comment to a closed bug.
Looking at grep's small body of code for handling the -f
option, I don't see anything substantially different between
3.1 and 3.7. It's the same logic wrapped around the fread
function.
Though the code has been worked on, there is no d
On 8/19/21 5:59 PM, Kaz Kylheku wrote:
This reproduces on grep 3.1 on Ubuntu.
That's a pretty old version of grep. I cannot reproduce the problem on
Ubuntu 21.04, which has grep 3.6. So it sounds like the bug is fixed,
and you can fix your problem by upgrading to a more-recent Ubuntu version.
My fading recollection from long, long ago is that this is a difficult to
avoid artifact of using stdio.
If no patterns are fed into grep, just a single EOF, then grep exits
immediately.
But some non-empty input (just a single "pat1" is sufficient) is fed to grep,
then it takes two EOF's to get
This reproduces on grep 3.1 on Ubuntu.
The command:
grep -f -
should accept a list of patterns from standard input, like this:
$ grep -f -
pat1
pat2
pat3
[Ctrl-D]
Upon receiving the EOF indication (zero byte read), the program
should immediately conclude that the list of pat
