Re^3: readline succeeds but sets $! = EBADF

Two thoughts.

First, why not use eof to check for an end-of-file condition?

Second, a common way to handle this situation is to close the filehandle after readline returns undef, and see if the close fails. If it does, there was some kind of error handling the file.

Comment on Re^3: readline succeeds but sets $! = EBADF Select or Download Code

Replies are listed 'Best First'.
Re^4: readline succeeds but sets $! = EBADF by ambrus (Abbot) on Aug 31, 2004 at 10:18 UTC
No, that's not true. Close returns an error only if an IO error (including broken network in case of nfs) has occured after the last write so the kernel couldn't report it sooner. From close(2): Not checking the return value of close is a common but nevertheless serious pro- gramming error. It is quite possible that errors on a previous write(2) operation are first reported at the final close. Not checking the return value when closing the file may lead to silent loss of data. This can especially be observed with NFS and disk quotas.	[reply]

Replies are listed 'Best First'.

Re^4: readline succeeds but sets $! = EBADF
by ambrus (Abbot) on Aug 31, 2004 at 10:18 UTC

No, that's not true. Close returns an error only if an IO error (including broken network in case of nfs) has occured after the last write so the kernel couldn't report it sooner.

From close(2):

Not checking the return value of close is a common but nevertheless serious pro- gramming error. It is quite possible that errors on a previous write(2) operation are first reported at the final close. Not checking the return value when closing the file may lead to silent loss of data. This can especially be observed with NFS and disk quotas.

[reply]