spurious warning when fd 1 gets re-opened for input #3905

p5pRT · 2001-04-22T15:38:17Z

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

Searchable as RT6875$

p5pRT · 2001-04-22T15:38:17Z

From @nwc10

$ perl -we 'close STDOUT; open FH, "/etc/motd" or die $!; warn fileno FH'
'stdout' opened only for input at -e line 1.
1 at -e line 1.

That warning about 'stdout' opened for input only is spurious.
However, I'm not quite sure how to avoid the false alarm whilst still
correctly protecting things when the real STDOUT is opened for input only.

It appeared somewhere bewteen 5.6.0 and 5.7.0

$ perl5.005 -we 'close STDOUT; open FH, "/etc/motd" or die $!; warn fileno FH'
1 at -e line 1.
$ perl5.6.0 -we 'close STDOUT; open FH, "/etc/motd" or die $!; warn fileno FH'
1 at -e line 1.
$ perl5.7.0 -we 'close STDOUT; open FH, "/etc/motd" or die $!; warn fileno FH'
'stdout' opened only for input at -e line 1.
1 at -e line 1.

I don't have a 5.6.1 here to test with.

[for some reason probably my fault perlbug is for 5.7.0, but "perl" is 5.7.1]

Nicholas Clark

Perl Info


Flags:
    category=core
    severity=low

This perlbug was built using Perl v5.7.0 - Sun Mar 25 14:52:17 BST 2001
It is being executed now by  Perl v5.7.0 - Fri Mar 30 20:19:52 BST 2001.

Site configuration information for perl v5.7.0:

Configured by nick at Fri Mar 30 20:19:52 BST 2001.

Summary of my perl5 (revision 5.0 version 7 subversion 0) configuration:
  Platform:
    osname=linux, osvers=2.4.0-rmk3, archname=armv4l-linux
    uname='linux bagpuss.unfortu.net 2.4.0-rmk3 #3 sat jan 20 21:38:55 gmt 2001 armv4l unknown '
    config_args='-Dmksymlinks -Dusedevel -Ubincompat5005 -Uinstallusrbinperl -Dcf_email=nick@talking.bollo.cx -Dperladmin=nick@talking.bollo.cx -Dinc_version_list=  -Dinc_version_list_init=0 -de'
    hint=recommended, useposix=true, d_sigaction=define
    usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef
    useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
    use64bitint=undef use64bitall=undef uselongdouble=undef
  Compiler:
    cc='cc', ccflags ='-fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
    optimize='-O2',
    cppflags='-fno-strict-aliasing -I/usr/local/include'
    ccversion='', gccversion='2.95.2 20000220 (Debian GNU/Linux)', gccosandvers=''
    intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=8
    ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
    alignbytes=4, usemymalloc=n, prototype=define
  Linker and Libraries:
    ld='cc', ldflags =' -L/usr/local/lib'
    libpth=/usr/local/lib /lib /usr/lib
    libs=-lnsl -lndbm -ldb -ldl -lm -lc -lposix -lcrypt -lutil
    perllibs=-lnsl -ldl -lm -lc -lposix -lcrypt -lutil
    libc=/lib/libc-2.1.3.so, so=so, useshrplib=false, libperl=libperl.a
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic'
    cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib'

Locally applied patches:
    DEVEL9274


@INC for perl v5.7.0:
    /usr/local/lib/perl5/5.7.0/armv4l-linux
    /usr/local/lib/perl5/5.7.0
    /usr/local/lib/perl5/site_perl/5.7.0/armv4l-linux
    /usr/local/lib/perl5/site_perl/5.7.0
    /usr/local/lib/perl5/site_perl
    .


Environment for perl v5.7.0:
    HOME=/home/nick
    LANG (unset)
    LANGUAGE (unset)
    LC_CTYPE=en_GB.ISO-8859-1
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/home/nick/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games:/sbin:/usr/sbin:/usr/local/sbin
    PERL_BADLANG (unset)
    SHELL=/bin/bash

p5pRT · 2001-04-22T21:15:34Z

From @andk

> This is a bug report for perl from nick@talking.bollo.cx,
> generated with the help of perlbug 1.33 running under perl v5.7.0.

> -----------------------------------------------------------------
> [Please enter your report here]

> $ perl -we 'close STDOUT; open FH, "/etc/motd" or die $!; warn fileno FH'
> 'stdout' opened only for input at -e line 1.
> 1 at -e line 1.

> That warning about 'stdout' opened for input only is spurious.
> However, I'm not quite sure how to avoid the false alarm whilst still
> correctly protecting things when the real STDOUT is opened for input only.

> It appeared somewhere bewteen 5.6.0 and 5.7.0

Accoring to my archive these two and 5.6.1 were OK and "it" happened
in patch 9301.

p5pRT · 2001-04-23T05:17:54Z

From @nwc10

Well, I had second thoughts. I *believe* that it might be helpful warning
that due to your course of actions you've succeeded in opening file
descriptor 1 for input, and this might cause problems with things than you
fork. However, I'm not convinced.

Anyway. I believe that this is a real bug, as my program fails:

perl5.6.0 -we 'close STDOUT; open FH, "</etc/motd" or die $!; open FH, ">/tmp/foo" or die $!; print FH "Bang\n" or die "Gonner: $!"'
Gonner: Bad file descriptor at -e line 1.

but if I close FH before opening it for output again:

perl5.6.0 -we 'close STDOUT; open FH, "</etc/motd" or die $!; close FH; open FH, ">/tmp/foo" or die $!; print FH "Bang\n" or die "Gonner: $!"'

It works.

Am I right in thinking that I shouldn't need to explicity close a filehandle
before re-opening it? There is no error condition on the input file handle.

[same bug in 5.7.0 and 5.7.1]

Nicholas Clark

PS Reason for all this closing of STDOUT is that Devel::Selfstubber spits all
output direct to STDOUT, so writing a regression test involves some
dup'ing, as where are all those "Ok" messages going? :-)

p5pRT · 2001-04-25T00:58:20Z

From [Unknown Contact. See original ticket]

Does it write to STDOUT or just print without a handle?
The latter can be handled by a suitable select().

p5pRT · 2001-04-25T01:00:47Z

From [Unknown Contact. See original ticket]

That was the intent of the warning. I am not 100% sure about it either,
it used to be worse...

Anyway. I believe that this is a real bug, as my program fails:

perl5.6.0 -we 'close STDOUT; open FH, "</etc/motd" or die $!; open FH, ">/tmp/foo" or die $!; print FH "Bang\n" or die "Gonner: $!"'
Gonner: Bad file descriptor at -e line 1.

but if I close FH before opening it for output again:

perl5.6.0 -we 'close STDOUT; open FH, "</etc/motd" or die $!; close FH; open FH, ">/tmp/foo" or die $!; print FH "Bang\n" or die "Gonner: $!"'

It works.

Am I right in thinking that I shouldn't need to explicity close a filehandle
before re-opening it?

You are correct - it should not be necessary.

There is no error condition on the input file handle.

[same bug in 5.7.0 and 5.7.1]

"Good" - at least that means I haven't broken _that_ with PerlIO isms.

p5pRT · 2001-04-26T10:36:28Z

From @nwc10

So, to be consistent shouldn't

close STDOUT;
open FH, ">foo";

warn me if file descriptor 1 has become associated with a file as part of
an open not associated with STDOUT, as I might get surprises when I fork
and things write to my file?

Probably that's a silly suggestion, but
close STDERR;
open FH, ">foo";

is more likely to cause problems as rather a lot of things assume that
it's fine to write to file descriptor 2 to report errors.

So should perl attempt to avoid descriptors 0,1,2 except for opens associated
with STDIN. STDOUT and STDERR?

Nicholas Clark

p5pRT · 2001-04-26T10:57:38Z

From [Unknown Contact. See original ticket]

So should perl attempt to avoid descriptors 0,1,2 except for opens associated
with STDIN. STDOUT and STDERR?

Dunno, but there was at least one other bug report about this same
issue. See

http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2001-03/msg00745.html

and the (short) thread that ensued. Since at least two people have been
tripped by this (and have bothered to file a report), it's probably worth
the effort for some kind of fix.

Cheers,
-Ben

p5pRT · 2011-11-23T03:28:16Z

From @jkeenan

On Sun Apr 22 08:38:17 2001, nick@talking.bollo.cx wrote:

$ perl -we 'close STDOUT; open FH, "/etc/motd" or die $!; warn fileno
FH'
'stdout' opened only for input at -e line 1.
1 at -e line 1.

That warning about 'stdout' opened for input only is spurious.
However, I'm not quite sure how to avoid the false alarm whilst still
correctly protecting things when the real STDOUT is opened for input
only.

It appeared somewhere bewteen 5.6.0 and 5.7.0

$ perl5.005 -we 'close STDOUT; open FH, "/etc/motd" or die $!; warn
fileno FH'
1 at -e line 1.
$ perl5.6.0 -we 'close STDOUT; open FH, "/etc/motd" or die $!; warn
fileno FH'
1 at -e line 1.
$ perl5.7.0 -we 'close STDOUT; open FH, "/etc/motd" or die $!; warn
fileno FH'
'stdout' opened only for input at -e line 1.
1 at -e line 1.

The warning is still present, albeit with slightly different wording, in
Perl 5.14.2:

###
$ perl -we 'close STDOUT; open FH, "/etc/motd" or die $!; warn fileno FH'
Filehandle STDOUT reopened as FH only for input at -e line 1.
1 at -e line 1.
###

toddr · 2020-02-04T22:33:41Z

Still present in 5.30

p5pRT added Severity Low distro-Linux type-core labels Oct 18, 2019

exodist mentioned this issue Feb 8, 2020

yath warns of "Filehandle STDOUT reopened as $fh only for input" Test-More/Test2-Harness#55

Closed

xenu removed the Severity Low label Dec 29, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

spurious warning when fd 1 gets re-opened for input #3905

spurious warning when fd 1 gets re-opened for input #3905

p5pRT commented Apr 22, 2001

p5pRT commented Apr 22, 2001

p5pRT commented Apr 22, 2001

p5pRT commented Apr 23, 2001

p5pRT commented Apr 25, 2001

p5pRT commented Apr 25, 2001

p5pRT commented Apr 26, 2001

p5pRT commented Apr 26, 2001

p5pRT commented Nov 23, 2011

toddr commented Feb 4, 2020

Navigation Menu

spurious warning when fd 1 gets re-opened for input #3905

spurious warning when fd 1 gets re-opened for input #3905

Comments

p5pRT commented Apr 22, 2001

p5pRT commented Apr 22, 2001

From @nwc10

p5pRT commented Apr 22, 2001

From @andk

p5pRT commented Apr 23, 2001

From @nwc10

p5pRT commented Apr 25, 2001

From [Unknown Contact. See original ticket]

p5pRT commented Apr 25, 2001

From [Unknown Contact. See original ticket]

p5pRT commented Apr 26, 2001

From @nwc10

p5pRT commented Apr 26, 2001

From [Unknown Contact. See original ticket]

p5pRT commented Nov 23, 2011

From @jkeenan

toddr commented Feb 4, 2020