3 ms·

Stupid question: in the cases where the input is a regular file, why doesn’t grep check the size of the file at the beginning? Is t actually desired behavior to

Stupid question: in the cases where the input is a regular file, why doesn’t grep check the size of the file at the beginning? Is t actually desired behavior to search through stuff added to the file while we are processing the beginning of it?

deleted 9y ago
[deleted]
tinus_hn 9y ago
The rules are that you open the file for reading until you get end-of-file. If you don’t follow the rules unexpected things go wrong. For instance it may not even be possible to get the file size. That is not suitable for a program like grep.
rocqua 9y ago
In Unix we have the idiom of "Everything Is A File". As such, when grep gets a file descriptor, it cannot always get the file-size, the file-size might be infinite, or might vary over time. Instead, like other have said, the only way to know you've read 'until the end' is to read reports you've reached the end of the file. Consider for example what should happen when grepping /dev/null/? Or, a more sensible case, piping the output of some command to grep. Grep will read from 'standard in' which is "Just A File" so it just calls read until it reports end of file.
- jameshart 9y ago
  But the article shows GNU grep actually looks ‘behind the curtain’ and identifies that input and output are the same file, then refuses to play. So everything is a file, but some are more filey than others.
- IgorPartola 9y ago
  > Consider for example what should happen when grepping /dev/null/ In the solution I gave, same thing as before because I said regular file. That is if you can open /dev/null for reading, which I thought you couldn't. I think I'd be fine with saying that the infinite loop is the behavior that happens. GNU's grep obviously is doing some janky check which it shouldn't be. Consider what it will do when you get just slightly more clever and it can't determine the input/output types. The one on macOS has arbitrary file size-dependent behavior, which is problematic. Doesn't seem like either of them does a consistent thing.

deleted 9y ago

[deleted]

tinus_hn 9y ago

The rules are that you open the file for reading until you get end-of-file. If you don’t follow the rules unexpected things go wrong. For instance it may not even be possible to get the file size. That is not suitable for a program like grep.

rocqua 9y ago

In Unix we have the idiom of "Everything Is A File". As such, when grep gets a file descriptor, it cannot always get the file-size, the file-size might be infinite, or might vary over time. Instead, like other have said, the only way to know you've read 'until the end' is to read reports you've reached the end of the file. Consider for example what should happen when grepping /dev/null/? Or, a more sensible case, piping the output of some command to grep. Grep will read from 'standard in' which is "Just A File" so it just calls read until it reports end of file.

jameshart 9y ago
But the article shows GNU grep actually looks ‘behind the curtain’ and identifies that input and output are the same file, then refuses to play. So everything is a file, but some are more filey than others.
IgorPartola 9y ago
> Consider for example what should happen when grepping /dev/null/ In the solution I gave, same thing as before because I said regular file. That is if you can open /dev/null for reading, which I thought you couldn't. I think I'd be fine with saying that the infinite loop is the behavior that happens. GNU's grep obviously is doing some janky check which it shouldn't be. Consider what it will do when you get just slightly more clever and it can't determine the input/output types. The one on macOS has arbitrary file size-dependent behavior, which is problematic. Doesn't seem like either of them does a consistent thing.