Skip to main content

You are not logged in. Your edit will be placed in a queue until it is peer reviewed.

We welcome edits that make the post easier to understand and more valuable for readers. Because community members review edits, please try to make the post substantially better than how you found it, for example, by fixing grammar or adding additional resources and hyperlinks.

Required fields*

6
  • Why would you expect this to hang instead of simply returning 4096 bytes and exiting? I don't know much about this kind of thing, but it seems odd to expect it to hang. What does tail -c 4097 /dev/zero | wc -c tell you? Doesn't it return 4097? It does on my Arch. Commented Apr 16 at 10:51
  • 2
    @terdon, they said it there: "since /dev/zero is an endless stream". tail -c is supposed to print the last N bytes, but you can't find the "last" bytes of an endless stream. Of course, when reading from a seekable file (instead of a pipe), tail could just seek to the correction position, and read the requested amount, which that strace shows it doing, and the seek even succeeds. But why does the requested amount of bytes change what it does after, who knows. Commented Apr 16 at 11:20
  • Ah, right, yes. I see what you mean, thanks @ilkkachu. Weird then, both 4096 and 4097 return exactly 4096 or 4097 bytes and exit on my Arch. Same with /dev/random and /dev/urandom. Commented Apr 16 at 11:28
  • I forgot to say, I got what the post above shows with tail from GNU coreutils 8.32 on Ubuntu, but I suspect this could depend very much on the implementation, since something like /dev/zero is a bit of an oddball case. Commented Apr 16 at 11:41
  • Busybox tail does hang with the same arguments that cause GNU tail exit immediately on my Arch Linux system Commented Apr 16 at 13:06