The 'do' function does not clear $! if it fails to compile it's argument

[p5pRT]

Migrated from rt.perl.org#85976 (status was 'open')

Searchable as RT85976$

[p5pRT]

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.

Perl Info

``` 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 ```

[p5pRT]

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

[p5pRT]

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

[p5pRT]

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

[p5pRT]

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

[p5pRT]

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

[p5pRT]

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