Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Not OK: perl 5.00563 on i386-bsdos 4.0 (UNINSTALLED) #932

Closed
p5pRT opened this issue Dec 10, 1999 · 1 comment
Closed

Not OK: perl 5.00563 on i386-bsdos 4.0 (UNINSTALLED) #932

p5pRT opened this issue Dec 10, 1999 · 1 comment

Comments

@p5pRT
Copy link

p5pRT commented Dec 10, 1999

Migrated from rt.perl.org#1875 (status was 'resolved')

Searchable as RT1875$

@p5pRT
Copy link
Author

p5pRT commented Dec 10, 1999

From rd@thrush.com

  All tests pass except one subtest in "pragma/warnings". The
  problem appears to be related to detecting input from
  filehandle dup'd from STDOUT.

  Here's a snippet from the "make test" results​:

cd t && (rm -f perl; /bin/ln -s ../perl perl)
if (true </dev/tty) >/dev/null 2>&1; then cd t && LD_LIBRARY_PATH=/u2/u4/work/bsdi/perl5.005_63​: ./perl TEST </dev/tty; else cd t && PERL_SKIP_TTY_TEST=1 LD_LIBRARY_PATH=/u2/u4/work/bsdi/perl5.005_63​: ./perl TEST; fi
base/cond...........ok
  [...]
pragma/utf8.........ok
pragma/warnings.....PROG​:
# pp_hot.c [pp_print]
use warnings 'io' ;
print STDIN "anc";
print <STDOUT>;
print <STDERR>;
open(FOO, ">&STDOUT") and print <FOO>;
print getc(STDERR);
print getc(FOO);
####################################################################
# The next test is known to fail on some systems (Linux/BSD+glibc, #
# NeXT among others. glibc should be fixed in the next version, #
# but it appears other platforms have little hope. We skip it for #
# now (on the grounds that it is "just" a warning). #
####################################################################
#read(FOO,$_,1);
no warnings 'io' ;
print STDIN "anc";
EXPECTED​:
Filehandle main​::STDIN opened only for input at - line 3.
Filehandle main​::STDOUT opened only for output at - line 4.
Filehandle main​::STDERR opened only for output at - line 5.
Filehandle main​::FOO opened only for output at - line 6.
Filehandle main​::STDERR opened only for output at - line 7.
Filehandle main​::FOO opened only for output at - line 8.
GOT​:
Filehandle main​::STDIN opened only for input at - line 3.
Filehandle main​::STDOUT opened only for output at - line 4.
Filehandle main​::STDERR opened only for output at - line 5.
Filehandle main​::STDERR opened only for output at - line 7.
FAILED at test 215
lib/abbrev..........ok
  [...]
Failed 1 test script out of 226, 99.56% okay.
u=2.06667 s=1.58333 cu=111.033 cs=31.5833 scripts=226 tests=11094

  Since the problem appeared to be failure to detect reading from
  a dup'd output filehandle, I reduced the test to​:

use warnings 'io';
open(FOO, ">&STDOUT") and print <FOO>;

  Running the above snippet from the commandline, ie.​:

export LD_LIBRARY_PATH=/u2/u4/work/bsdi/perl5.005_63
./perl -I../lib /tmp/tmp0004

  works as expected and produces the result​:

Filehandle main​::FOO opened only for output at /tmp/tmp0004 line 2.

  However, running the same program sequence within the test harness
  results in no output.

  Investigating further, I noticed that the following program​:

use warnings 'io';
open(FOO, ">&STDERR") and print <FOO>;
open(BAR, ">&STDOUT") and print <BAR>;
open(FOO, ">xyzzy") or die "Can't create \"xyzzy\"​: $!";
open(BAR, ">&FOO") and print <BAR>;

  run from the commandline results in​:

Filehandle main​::FOO opened only for output at /tmp/tmp0004 line 2.
Filehandle main​::BAR opened only for output at /tmp/tmp0004 line 3.
Filehandle main​::BAR opened only for output at /tmp/tmp0004 line 5.

  which appears to be as expected. However, when run from this
  wrapper​:

use warnings 'io';
my $result=`./perl -I../lib /tmp/tmp0004`;
print $result, "\n";

  the results are​:

Filehandle main​::FOO opened only for output at /tmp/tmp0004 line 2.
Filehandle main​::BAR opened only for output at /tmp/tmp0004 line 5.

  Something unexpected happens when the STDOUT filehandle is
  dup'd in a child process...

Perl Info


Site configuration information for perl 5.00563:

Configured by root at Fri Dec 10 13:50:28 EST 1999.

Summary of my perl5 (revision 5.0 version 5 subversion 63) configuration:
  Platform:
    osname=bsdos, osvers=4.0, archname=i386-bsdos
    uname='bsdos tarpit.thrush.com 4.0 bsdi bsdos 4.0 kernel #2: sun mar 21 03:57:22 est 1999 rd@tarpit.thrush.com:usrsrcsyscompilelocal i386 '
    config_args='-des -Dprefix=/opt/perl'
    hint=recommended, useposix=true, d_sigaction=define
    usethreads=undef useperlio=undef d_sfio=undef
    use64bits=undef usemultiplicity=undef
  Compiler:
    cc='cc', optimize='-O2', gccversion=2.7.2.1
    cppflags='-I/usr/local/include'
    ccflags ='-I/usr/local/include'
    stdchar='char', d_stdstdio=undef, usevfork=false
    intsize=4, longsize=4, ptrsize=4, doublesize=8
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
    alignbytes=4, usemymalloc=n, prototype=define
  Linker and Libraries:
    ld='ld', ldflags =' -L/usr/X11/lib -L/usr/local/lib'
    libpth=/usr/local/lib /usr/shlib /shlib /usr/lib /usr/X11/lib
    libs=-ldl -lm -lc
    libc=/shlib/libc.so, so=so, useshrplib=true, libperl=libperl.so
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' '
    cccdlflags='-fPIC', lddlflags='-shared -x  -L/usr/X11/lib -L/usr/local/lib'

Locally applied patches:
    


@INC for perl 5.00563:
    lib
    /opt/perl/lib/5.00563/i386-bsdos
    /opt/perl/lib/5.00563
    /opt/perl/lib/site_perl/5.00563/i386-bsdos
    /opt/perl/lib/site_perl
    .


Environment for perl 5.00563:
    HOME=/home/rd
    LANG (unset)
    LANGUAGE (unset)
    LD_LIBRARY_PATH=/u2/u4/work/bsdi/perl5.005_63:
    LOGDIR (unset)
    PATH=/home/rd/bin:/usr/local/bin:/usr/local/samba/bin:/sbin:/usr/sbin:/bin:/usr/bin:/usr/contrib/bin:/usr/X11/bin
    PERL_BADLANG (unset)
    SHELL=/bin/bash

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant