$ perl -le 'open F, "gobbledegook" or print "WARN1: $!"; print "PRINT:
+ $!"; readlink "test" or print "WARN2: $!";  print "PRINT: $!'
WARN1: No such file or directory
PRINT: No such file or directory
WARN2: Invalid argument
PRINT: Invalid argument
[download]

$ perl -e 'print "BANG: $!"'
BANG:

$ perl -Mstrict -e 'print "BANG: $!"'
BANG: Bad file descriptor
[download]

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
  }
  # ...
}
[download]

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;
[download]

produces:

n=5 s=I/O error
n=6 s=No such device or address
n=0 s=
[download]

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.

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:
[download]

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)
[download]

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