You're wrong about the use of $!, at least on unix. The errno variable is not cleared by successful system calls, but it is set by failing ones. In order to distinguish successful and failing system calls by the use of errno alone, it is necessary to clear errno before making the system call.
Here's the relevant part of the readline documentation:
... until end-of-file is reached, whereupon the subsequent call returns undef.
If readline encounters an operating system error, $! will be set with the corresponding error message. It can be helpful to check $! when you are reading from filehandles you don't trust, such as a tty or a socket. The following example uses the operator form of readline, and takes the necessary steps to ensure that readline was successful.
for (;;) {
undef $!;
unless (defined( $line = <> )) {
die $! if $!;
last; # reached EOF
}
# ...
}
Based on the documentation, readline returns undef in two cases: EOF or I/O error. In the case of EOF, $! (or errno) is not modified and will have the value it had before readline was called, since the system call(s) have not failed. In the case of an I/O error, $! will have the corresponding errno value which resulted from the failing system call. In order to distinguish them, $! must be cleared before calling readline. If $! were not cleared, then after a call to readline which reached EOF, it would still have the same value it had before the call. If that value happened to be non-zero (which your examples show can easily happen), then it would appear that readline returned undef because an I/O error occurred.
Here is some code which demonstrates that $! retains its value from before the readline call when EOF is reached and that therefore it is essential to clear $! in order to distinguish an I/O error from EOF.
#!/usr/bin/perl
sub doit {
open FH, shift or die "open failure: $!\n";
$! = shift;
1 while <FH>;
$n = $!+0;
print "n=$n s=$!\n";
}
doit $0, 5;
doit $0, 6;
doit $0, undef;
produces:
n=5 s=I/O error
n=6 s=No such device or address
n=0 s=
| [reply]
[d/l]
[select] |
In the case of EOF, $! (or errno) is not modified and will have the value it had before readline was called, since the system call(s) have not failed.
That's wrong, according to the docs for $!. The value of $! is undefined if no error has occured. You cannot count on it being unchanged.
Furthermore, it's observably wrong on my system. $! does not remain unchanged after EOF, or even after reading a line successfully.
To answer your earlier question, yes, readline is wrong.
| [reply]
[d/l]
[select] |
Well, if you ran my test program (see above) on unix and got different results than I did, then I will have to defer to an observable fact that different versions of perl handle this differently. But on all the unix machines I've tested this on, it is 100% consistent (I will concede that Windows perl handles this differently).
Plus, the docs for $! state "after a failure". There is no definition for "failure" given, but I assume it means after readline returns undef, which it does on both EOF and I/O error. Therefore, it is valid to check the value of $! in the case under consideration, since readline has returned undef.
Could you please post the output of "uname -a" on the version of unix where you ran my test program and the version of perl you used to run it? Here are my results for a variety of perl versions and unices, plus Windows XP. The only version that displays the strange behavior of modifying $! on EOF is Windows XP.
| [reply]
[d/l] |
Since Windows perl (ActiveState) does modify $! on both EOF and I/O error, how can those two cases be distinguished (i.e. when readline returns undef)?
| [reply] |
You're wrong about the use of $!, at least on unix.
I don't think I am wrong about $! at all, I just follow it's convention according to the documentation. If as you say $! holds the current errno , then as per perlvar, you're clearly wrong about wanting to use it to use it to determine failure of a system call. If i may quote from a section about $! in perlvar.
If used numerically, yields the current value of the C errno variable,
+ or in other words, if a system or library call fails, it sets this v
+ariable. This means that the value of $! is meaningful only immediat
+ely after a failure:
The errno variable is not cleared by successful system calls, but it is set by failing ones.
$! is definitely set after a failed system/library call, no doubt about that. The docs say it is not set to zero after success, they do not say it remains unchanged (and that's what you have to watch out for). $! is sometimes cleared after successful calls while also being set in certain other instances. Here's your own code demonstrating both possibilities.
#!/usr/bin/perl -Wl
sub doit {
$! = undef;
open FH, shift or die "open failure: $!\n";
print "After successful open : $!";
1 while readline FH;
print "After successful read : $!";
}
doit $0, 5;
doit $0, 6;
doit $0, undef;
__END__
___output___
___linux___
After successful open : Inappropriate ioctl for device
After successful read :
After successful open : Inappropriate ioctl for device
After successful read :
After successful open : Inappropriate ioctl for device
After successful read :
$ perl -e 'print $]'
5.008008
$ uname -a
Linux cond0 2.6.17-10-386 #2 Fri Oct 13 18:41:40 UTC 2006 i686 GNU/Lin
+ux
$ cat /etc/issue
Ubuntu 6.10 \n \l
___windows___
Name "main::FH" used only once: possible typo at read.pl line 4.
After successful open :
After successful read : Bad file descriptor
After successful open :
After successful read : Bad file descriptor
After successful open :
After successful read : Bad file descriptor
$ perl -e "print $]"
5.008006
$ ver
Microsoft Windows [Version 5.2.3790]
$ type c:\boot.ini | perl -ne "print $1 if /\"(.*)\"/"
Windows NT 5.2(3790.srv03.SP1.rtm.050324-1447)
In order to distinguish successful and failing system calls by the use of errno alone
Please don't do that for the sakes of portability and convention, do what everyone else does, use $! only to determine the cause to a failure of a system/library call. If, in doubt, consult the documentation about this variable in perlvar, it is straight-forward and I should imagine it takes precedence over any other documentation that offers any ambiguity.
perl -e '$,=$",$_=(split/\W/,$^X)[y[eval]]]+--$_],print+just,another,split,hack'er
| [reply]
[d/l]
[select] |