From zby@cpan.org

Created by zby@cpan.org

Running this code​:

do 'example.pl' or print "\$!​: $!\n";
print "\$\@​​: $@​\n";

assumming that 'example.pl' in current directory contains​:

use NonExisting;

Results in​:

$!​: No such file or directory
$@​​: Can't locate NonExisting.pm in @​INC (@​INC contains​:
/home/zby/perl5/perlbrew/perls/perl-5.12.3/lib/site_perl/5.12.3/x86_64-linux
/home/zby/perl5/perlbrew/perls/perl-5.12.3/lib/site_perl/5.12.3
/home/zby/perl5/perlbrew/perls/perl-5.12.3/lib/5.12.3/x86_64-linux
/home/zby/perl5/perlbrew/perls/perl-5.12.3/lib/5.12.3 .) at example.pl line
1.
BEGIN failed--compilation aborted at example.pl line 1.

I.e. both "$!" and "$@​" are set.

The documentation of 'do' says​:

If "do" cannot read the file, it returns undef and sets $! to
the error. If "do" can read the file but cannot compile it, it
returns undef and sets an error message in $@​.

This does not, strictly speaking, preclude the current behaviour,
but I think most people, if not warned, would understand this to mean
that $! is set only in the case when the file cannot be found.

The current behavious is probably a result of not clearing $!, set
by the failed @​INC searches, by "do" after the compilation fails.

Flags:
    category=core
    severity=low

Site configuration information for perl 5.12.3:

Configured by zby at Sat Jan 22 22:01:16 CET 2011.

Summary of my perl5 (revision 5 version 12 subversion 3) configuration:

  Platform:
    osname=linux, osvers=2.6.35-24-generic, archname=x86_64-linux
    uname='linux zby 2.6.35-24-generic #42-ubuntu smp thu dec 2 02:41:37 utc
2010 x86_64 gnulinux '
    config_args='-de -Dprefix=/home/zby/perl5/perlbrew/perls/perl-5.12.3'
    hint=recommended, useposix=true, d_sigaction=define
    useithreads=undef, usemultiplicity=undef
    useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
    use64bitint=define, use64bitall=define, uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='cc', ccflags ='-fno-strict-aliasing -pipe -fstack-protector
-I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
    optimize='-O2',
    cppflags='-fno-strict-aliasing -pipe -fstack-protector
-I/usr/local/include'
    ccversion='', gccversion='4.4.5', gccosandvers=''
    intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
    ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t',
lseeksize=8
    alignbytes=8, prototype=define
  Linker and Libraries:
    ld='cc', ldflags =' -fstack-protector -L/usr/local/lib'
    libpth=/usr/local/lib /lib /usr/lib /lib64 /usr/lib64
    libs=-lnsl -ldl -lm -lcrypt -lutil -lc
    perllibs=-lnsl -ldl -lm -lcrypt -lutil -lc
    libc=/lib/libc-2.12.1.so, so=so, useshrplib=false, libperl=libperl.a
    gnulibc_version='2.12.1'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
    cccdlflags='-fPIC', lddlflags='-shared -O2 -L/usr/local/lib
-fstack-protector'

Locally applied patches:



@INC for perl 5.12.3:

 /home/zby/perl5/perlbrew/perls/perl-5.12.3/lib/site_perl/5.12.3/x86_64-linux
    /home/zby/perl5/perlbrew/perls/perl-5.12.3/lib/site_perl/5.12.3
    /home/zby/perl5/perlbrew/perls/perl-5.12.3/lib/5.12.3/x86_64-linux
    /home/zby/perl5/perlbrew/perls/perl-5.12.3/lib/5.12.3
    .


Environment for perl 5.12.3:
    HOME=/home/zby
    LANG=pl_PL.utf8
    LANGUAGE (unset)
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)

 PATH=/home/zby/perl5/perlbrew/bin:/home/zby/perl5/perlbrew/perls/perl-5.12.3/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games

 PERLBREW_PATH=/home/zby/perl5/perlbrew/bin:/home/zby/perl5/perlbrew/perls/perl-5.12.3/bin
    PERLBREW_PERL=perl-5.12.3
    PERLBREW_ROOT=/home/zby/perl5/perlbrew
    PERLBREW_VERSION=0.13
    PERL_BADLANG (unset)
    SHELL=/bin/bash

From @pjcj

On Sat, Mar 12, 2011 at 01​:48​:12AM -0800, Zbigniew Lukasiak wrote​:

do 'example.pl' or print "\$!​: $!\n";
print "\$\@​​: $@​\n";

assumming that 'example.pl' in current directory contains​:

use NonExisting;

Results in​:

$!​: No such file or directory
$@​​: Can't locate NonExisting.pm in @​INC (@​INC contains​:
/home/zby/perl5/perlbrew/perls/perl-5.12.3/lib/site_perl/5.12.3/x86_64-linux
/home/zby/perl5/perlbrew/perls/perl-5.12.3/lib/site_perl/5.12.3
/home/zby/perl5/perlbrew/perls/perl-5.12.3/lib/5.12.3/x86_64-linux
/home/zby/perl5/perlbrew/perls/perl-5.12.3/lib/5.12.3 .) at example.pl line
1.
BEGIN failed--compilation aborted at example.pl line 1.

I.e. both "$!" and "$@​" are set.

The documentation of 'do' says​:

If "do" cannot read the file, it returns undef and sets $! to
the error. If "do" can read the file but cannot compile it, it
returns undef and sets an error message in $@​.

This does not, strictly speaking, preclude the current behaviour,
but I think most people, if not warned, would understand this to mean
that $! is set only in the case when the file cannot be found.

Unless they were familiar with errno, I suspect.

The current behavious is probably a result of not clearing $!, set
by the failed @​INC searches, by "do" after the compilation fails.

This general topic has been discussed before. I believe the consensus
is (or perhaps it's just my opinion) that​:

1. As you note, this isn't actually a bug. As documented in perlvar,
  and analogously to errno, $! only has meaning immediately after an
  error has occurred in a system or library call.

2. It is not always obvious when a library call occurs, nor what
  "immediately" means in this context. Ideally, a Perl programmer
  would be shielded from these details anyway.

3. Patches to improve the situation would probably be accepted provided
  any detrimental effect was manageable (performance, maintainability,
  clarity of documentation etc.).

4. This is probably not very far up the TODO list of anyone who is
  regularly patching perl.

--
Paul Johnson - paul@​pjcj.net
http​://www.pjcj.net

The RT System itself - Status changed from 'new' to 'open'

From @xdg

On Sat, Mar 19, 2011 at 12​:28 PM, Paul Johnson <paul@​pjcj.net> wrote​:

This general topic has been discussed before.  I believe the consensus
is (or perhaps it's just my opinion) that​:

 1. As you note, this isn't actually a bug.  As documented in perlvar,
   and analogously to errno, $! only has meaning immediately after an
   error has occurred in a system or library call.

 2. It is not always obvious when a library call occurs, nor what
   "immediately" means in this context.  Ideally, a Perl programmer
   would be shielded from these details anyway.

 3. Patches to improve the situation would probably be accepted provided
   any detrimental effect was manageable (performance, maintainability,
   clarity of documentation etc.).

 4. This is probably not very far up the TODO list of anyone who is
   regularly patching perl.

After Zbigniew uncovered this through CPAN Testers, I asked Zbigniew
to submit this so it wouldn't get lost.

As we're right up to the 5.14 freeze, I'll commit a documentation
clarification and maybe someone will tackle it eventually. Certainly,
as written, the docs are misleading.

-- David

From @doy

The documentation currently states​:

  Always check $@​ first, as compilation could fail in a way that also
sets $!.

Is this sufficient? I don't think we really want to be messing with the
semantics of $! in just this specific case.

-doy

From @jkeenan

The last two posts in this RT were from xdaveg (replying to pjcj) and
from doy​:

#####
On Sat Mar 19 18​:04​:55 2011, xdaveg@​gmail.com wrote​:

On Sat, Mar 19, 2011 at 12​:28 PM, Paul Johnson <paul@​pjcj.net> wrote​:

This general topic has been discussed before. I believe the consensus
is (or perhaps it's just my opinion) that​:

1. As you note, this isn't actually a bug. As documented in perlvar,
and analogously to errno, $! only has meaning immediately after an
error has occurred in a system or library call.

2. It is not always obvious when a library call occurs, nor what
"immediately" means in this context. Ideally, a Perl programmer
would be shielded from these details anyway.

3. Patches to improve the situation would probably be accepted provided
any detrimental effect was manageable (performance,
maintainability,
clarity of documentation etc.).

4. This is probably not very far up the TODO list of anyone who is
regularly patching perl.

After Zbigniew uncovered this through CPAN Testers, I asked Zbigniew
to submit this so it wouldn't get lost.

As we're right up to the 5.14 freeze, I'll commit a documentation
clarification and maybe someone will tackle it eventually. Certainly,
as written, the docs are misleading.

-- David

#####

On Tue Jul 03 17​:38​:20 2012, doy wrote​:

The documentation currently states​:

Always check $@​ first, as compilation could fail in a way that also
sets $!.

Is this sufficient? I don't think we really want to be messing with the
semantics of $! in just this specific case.

-doy

#####

David,

Did you ever submit the documentation patch mentioned above? If not, is
it still worth pursuing, given the point made by doy?

Let's see if we can push this ticket toward resolution.

Thank you very much.
Jim Keenan

From @xdg

On Mon, Jun 17, 2013 at 8​:35 PM, James E Keenan via RT
<perlbug-followup@​perl.org> wrote​:

Did you ever submit the documentation patch mentioned above? If not, is
it still worth pursuing, given the point made by doy?

Yes, the doc patch went in.

I care less about whether $! is cleared than that having to check two
error variables is obnoxious.

No one has volunteered to do that work.

I have no problem with the ticket remaining open at low priority.

--
David Golden <xdg@​xdg.me>
Take back your inbox! → http​://www.bunchmail.com/
Twitter/IRC​: @​xdg