If $fh is a pipe (stdin), then sysread will block and I will never try to seek on stdin, of which it is not capable
sysread will bock on pipes and sockets, unless you've specified unblocking behaviour. update: and you can't seek on pipes and sockets AFAIK, but seeking may flush system buffers.
If $fh is a file, the sysread will never block and at EOF the result will always be 0
AFAIK all reads block (i.e. wait for the data to arrive from disk, or network etc) unless you've got nonblocking behaviour. Reading on a file just won't block when you've reached EOF, similarly for closed pipes and sockets. I'm not sure if nonblocking behaviour does anything special on a file, but it might.
If $fh is a file, and the file gets renamed, the descriptor will not be affected and I will continue attempts to read from the same file
True.
If $fh is a file and it gets unlinked my open descriptor will maintain a reference to it, and I will not get an error - the file will simply stop growing, because no one will write to a non-existing file
True in a way, but if any other process already has that file open, they can still write to it, but if the file is completely unlinked (a file may have more than one entry point in the directory tree) you can't normally open() it (system specific tricks aside).
In reply to Re: Tailing a pipe or file
by Joost
in thread Tailing a pipe or file
by ribasushi
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |