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

IO::File reads garbage from directory filehandles #7514

Closed
p5pRT opened this issue Sep 27, 2004 · 21 comments
Closed

IO::File reads garbage from directory filehandles #7514

p5pRT opened this issue Sep 27, 2004 · 21 comments

Comments

@p5pRT
Copy link

p5pRT commented Sep 27, 2004

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

Searchable as RT31730$

@p5pRT
Copy link
Author

p5pRT commented Sep 27, 2004

From alester@flr.follett.com

Created by alester@flr.follett.com

I'm able to open a directory with IO​::File->new, and when I do, I
sometimes get garbage from getline(), but not alwaays. In the following
example, I get directory entries from my home directory, but undef from
/tmp, which does have files in it.

I don't WANT to be able to read from the filehandle, but it seems it
should reliably always return undef if I do. And if we ARE able to
read from the directory entries directly, then that should be documented
behavior.

alester@​dinger[~]$ cat iofile.pl
#!/usr/bin/perl -w

use strict;
use IO​::File;
use Data​::Dumper;

my $filename = shift || "/home/alester";
my $fh = IO​::File->new( $filename, "r" );
my $input_line = $fh->getline();
print Dumper( $filename, $fh, $input_line );

alester@​dinger[]$ ./iofile.pl
$VAR1 = '/home/alester';
$VAR2 = bless( \*Symbol​::GEN0, 'IO​::File' );
$VAR3 = 'Dc?
  .G?
  .bash_historyF?.sshu?.ncftpDc?.cvsrcDc?.vimrcDc.viminfo??
  binDc?
';
alester@​dinger[
]$ ./iofile.pl /tmp
$VAR1 = '/tmp';
$VAR2 = bless( \*Symbol​::GEN0, 'IO​::File' );
$VAR3 = undef;

Perl Info

Flags:
    category=library
    severity=high

Site configuration information for perl v5.8.2:

Configured by alester at Sat Jan 31 15:33:08 CST 2004.

Summary of my perl5 (revision 5.0 version 8 subversion 2) configuration:
  Platform:
    osname=solaris, osvers=2.8, archname=sun4-solaris
    uname='sunos dinger 5.8 generic_108528-16 sun4u sparc '
    config_args='-des -Accflags=-DPERL_POLLUTE -DDEBUGGING -Dcc=gcc -Dcf_email=alester@flr.follett.com -Dperladmin=alester@flr.follett.com'
    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
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='gcc', ccflags ='-DPERL_POLLUTE -DDEBUGGING -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
    optimize='-O',
    cppflags='-DPERL_POLLUTE -DDEBUGGING -fno-strict-aliasing -I/usr/local/include'
    ccversion='', gccversion='3.3', gccosandvers='solaris2.8'
    intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=4321
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
    ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
    alignbytes=8, prototype=define
  Linker and Libraries:
    ld='gcc', ldflags =' -L/usr/local/lib '
    libpth=/usr/local/lib /usr/lib /usr/ccs/lib
    libs=-lsocket -lnsl -ldb -ldl -lm -lc
    perllibs=-lsocket -lnsl -ldl -lm -lc
    libc=/lib/libc.so, so=so, useshrplib=false, libperl=libperl.a
    gnulibc_version=''
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' '
    cccdlflags='-fPIC', lddlflags='-G -L/usr/local/lib'

Locally applied patches:
    


@INC for perl v5.8.2:
    /usr/local/lib/perl5/5.8.2/sun4-solaris
    /usr/local/lib/perl5/5.8.2
    /usr/local/lib/perl5/site_perl/5.8.2/sun4-solaris
    /usr/local/lib/perl5/site_perl/5.8.2
    /usr/local/lib/perl5/site_perl
    .


Environment for perl v5.8.2:
    HOME=/home/alester
    LANG (unset)
    LANGUAGE (unset)
    LD_LIBRARY_PATH=/u01/app/oracle/product/8.1.7/lib:/usr/dt/lib:/usr/lib:/u01/app/oracle/product/8.1.7/ctx/lib
    LOGDIR (unset)
    PATH=/usr/local/bin:/usr/bin:/usr/sbin:/usr/ucb:/etc:/usr/ucb:/usr/ccs/bin:/usr/dt/bin:/usr/opt/SUNWmd/sbin:/usr/openwin/bin:/u01/app/oracle/product/8.1.7/bin:/bin:/u01/app/oracle/product/8.1.7/ctx/lib:/home/alester/tw/Dev:/opt/EMCpower/bin:/etc:/home/alester/bin:/home/alester/play
    PERL_BADLANG (unset)
    SHELL=/usr/bin/bash

@p5pRT
Copy link
Author

p5pRT commented Sep 27, 2004

From @smpeters

The decision of whether a directory can be accessed as a file is very
operating system dependent, even among POSIX systems.

I experimented on Linux with the script and simply "cat /tmp" to check
on the results. On Linux a "undef" is the result of $VAR3 in the dump
from the script. "cat /tmp" fails with the message "cat​: /tmp​: Is a
directory". The answer to why this happens comes from looking at the
strace output. The kernel returns an EISDIR when a read() is attempted
on a directory.

<snip>
read(3, 0x81fe800, 4096) = -1 EISDIR (Is a directory)
</snip>

My experience from Solaris and HP-UX (and other UNIXs) is that this
would not be the result and the kernel doesn't care whether a file is
truly a directory or not. Looking through a few man files for "read
()", it should fail if EISDIR is returned as an errno, but it appears
that many kernels don't return EISDIR.

Now, I guess the question is whether we want IO​::File's behavior
related to directories to change depending on the operating system or
not.

@p5pRT
Copy link
Author

p5pRT commented Sep 27, 2004

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

@p5pRT
Copy link
Author

p5pRT commented Sep 27, 2004

From ajs@ajs.com

On Mon, 2004-09-27 at 12​:12, Steve Peters via RT wrote​:

The decision of whether a directory can be accessed as a file is very
operating system dependent, even among POSIX systems.
[... demonstration that some systems return EISDIR ...]

Yes, you are correct. Historically, this is because directories used to
be implemented as files which opendir/readdir acted as a front-end to
(they just contained a packed array of dirents (or was it "direct"?)).
There are still programs that take advantage of this on those platforms.

Now, I guess the question is whether we want IO​::File's behavior
related to directories to change depending on the operating system or
not.

Absolutely yes. It's one of those situations where I think the best
standard to have is that it is considered undefined. You're going to run
into someone, somewhere, who is legitimately opening a directory for
reading as a file, and it should not be impossible for them. POSIX does
not, I think, take a stand on what you get when you open(2) a directory.

--
� 781-324-3772
â�� ajs@​ajs.com
â�· http​://www.ajs.com/~ajs

@p5pRT
Copy link
Author

p5pRT commented Sep 27, 2004

From perl5-porters@ton.iguana.be

In article <1096310497.1249.53.camel@​pps>,
  Aaron Sherman <ajs@​ajs.com> writes​:

Absolutely yes. It's one of those situations where I think the best
standard to have is that it is considered undefined. You're going to run
into someone, somewhere, who is legitimately opening a directory for
reading as a file, and it should not be impossible for them. POSIX does
not, I think, take a stand on what you get when you open(2) a directory.

I agree with you, but it still might be nice to have an option/flag that
means "must NOT be a directory"

@p5pRT
Copy link
Author

p5pRT commented Sep 27, 2004

From @Tux

On Mon 27 Sep 2004 20​:41, Aaron Sherman <ajs@​ajs.com> wrote​:

On Mon, 2004-09-27 at 12​:12, Steve Peters via RT wrote​:

The decision of whether a directory can be accessed as a file is very
operating system dependent, even among POSIX systems.
[... demonstration that some systems return EISDIR ...]

Yes, you are correct. Historically, this is because directories used to
be implemented as files which opendir/readdir acted as a front-end to
(they just contained a packed array of dirents (or was it "direct"?)).
There are still programs that take advantage of this on those platforms.

Now, I guess the question is whether we want IO​::File's behavior
related to directories to change depending on the operating system or
not.

Absolutely yes. It's one of those situations where I think the best
standard to have is that it is considered undefined. You're going to run
into someone, somewhere, who is legitimately opening a directory for
reading as a file, and it should not be impossible for them. POSIX does
not, I think, take a stand on what you get when you open(2) a directory.

--8<--- xx.c
#include <unistd.h>
#include <errno.h>
#include <fcntl.h>

int main (int argc, char *argv[])
{
  auto int i = open ("/tmp", O_RDONLY);
  perror ("open /tmp");
  printf ("open ('/tmp') = %d, errno = %d\n", i, errno);
  return (errno);
  } /* main */
-->8---

HP-UX 11.11 (11i)
r3​:/tmp 109 > ./xx
open /tmp​: Error 0
open ('/tmp') = 3, errno = 0
r3​:/tmp 110 >

HP-UX 11.00
a5​:/tmp 104 > ./xx
open /tmp​: Error 0
open ('/tmp') = 3, errno = 0
a5​:/tmp 105 >

HP-UX 10.20
d3​:/tmp 104 > ./xx
open /tmp​: Error 0
open ('/tmp') = 3, errno = 0
d3​:/tmp 105 >

AIX 5.2.0
i4​:/tmp 104 > ./xx
open /tmp​: Error 0
open ('/tmp') = 3, errno = 0
i4​:/tmp 105 >

AIX 4.3.3
i2​:/tmp 104 > ./xx
open /tmp​: Error 0
open ('/tmp') = 3, errno = 0
i2​:/tmp 105 >

SuSE 9.1 Linux 2.6.5-7.108-default
lt09​:/tmp 104 > ./xx
open /tmp​: Success
open ('/tmp') = 3, errno = 29
Exit 29
lt09​:/tmp 105 >

CYGWIN_NT-5.0 1.5.11(0.116/4/2)
PC09​:/tmp 506 $ ./xx
open /tmp​: No error
open ('/tmp') = 3, errno = 0
PC09​:/tmp 507 $

M$ Visual C++
C​:\Tmp>xx
open /tmp​: Permission denied
open ('/tmp') = -1, errno = 13

C​:\Tmp>

-- FWIW same message if I open "." or "\\Tmp"

--
H.Merijn Brand Amsterdam Perl Mongers (http​://amsterdam.pm.org/)
using perl-5.6.1, 5.8.3, & 5.9.x, and 809 on HP-UX 10.20 & 11.00, 11i,
  AIX 4.3, SuSE 9.0, and Win2k. http​://www.cmve.net/~merijn/
http​://archives.develooper.com/daily-build@​perl.org/ perl-qa@​perl.org
send smoke reports to​: smokers-reports@​perl.org, QA​: http​://qa.perl.org

@p5pRT
Copy link
Author

p5pRT commented Sep 28, 2004

From nick@ing-simmons.net

H.Merijn Brand <h.m.brand@​hccnet.nl> writes​:

--8<--- xx.c
#include <unistd.h>
#include <errno.h>
#include <fcntl.h>

int main (int argc, char *argv[])
{
auto int i = open ("/tmp", O_RDONLY);
perror ("open /tmp");
printf ("open ('/tmp') = %d, errno = %d\n", i, errno);
return (errno);
} /* main */
-->8---

HP-UX 11.11 (11i)
r3​:/tmp 109 > ./xx
open /tmp​: Error 0
open ('/tmp') = 3, errno = 0
r3​:/tmp 110 >
...

SuSE 9.1 Linux 2.6.5-7.108-default
lt09​:/tmp 104 > ./xx
open /tmp​: Success
open ('/tmp') = 3, errno = 29
Exit 29
lt09​:/tmp 105 >

CYGWIN_NT-5.0 1.5.11(0.116/4/2)
PC09​:/tmp 506 $ ./xx
open /tmp​: No error
open ('/tmp') = 3, errno = 0
PC09​:/tmp 507 $

M$ Visual C++
C​:\Tmp>xx
open /tmp​: Permission denied
open ('/tmp') = -1, errno = 13

C​:\Tmp>

-- FWIW same message if I open "." or "\\Tmp"

So all the Unix-oids (including cygwin!) let you open() a directory.
Linux happens to mess up errno as it does so.

Win32 doesn't let you - no real surprise.

@p5pRT
Copy link
Author

p5pRT commented Sep 28, 2004

From nick@ing-simmons.net

Aaron Sherman <ajs@​ajs.com> writes​:

On Mon, 2004-09-27 at 12​:12, Steve Peters via RT wrote​:

The decision of whether a directory can be accessed as a file is very
operating system dependent, even among POSIX systems.
[... demonstration that some systems return EISDIR ...]

Yes, you are correct. Historically, this is because directories used to
be implemented as files which opendir/readdir acted as a front-end to
(they just contained a packed array of dirents (or was it "direct"?)).
There are still programs that take advantage of this on those platforms.

And it seems that on Linux opendir() may still do an open(),
but readdir() isn't a read().

@p5pRT
Copy link
Author

p5pRT commented Sep 30, 2004

From @smpeters

[ni-s - Tue Sep 28 05​:52​:47 2004]​:

Aaron Sherman <ajs@​ajs.com> writes​:

On Mon, 2004-09-27 at 12​:12, Steve Peters via RT wrote​:

The decision of whether a directory can be accessed as a file is
very
operating system dependent, even among POSIX systems.
[... demonstration that some systems return EISDIR ...]

Yes, you are correct. Historically, this is because directories used
to
be implemented as files which opendir/readdir acted as a front-end to
(they just contained a packed array of dirents (or was
it "direct"?)).
There are still programs that take advantage of this on those
platforms.

And it seems that on Linux opendir() may still do an open(),
but readdir() isn't a read().

OK, at least it seems that we're in agreement that this behavior is
operating system dependent and that we don't want to change it since it
could break things for Perl users on environments where an open() on a
directory works.

Two points brought up remain, though.

* Do we want to add an optional argument to IO​::File->new() so that it
fails on an open attempt on a directory? The advantage of this would
be that it would allow for consistant cross-platform behavior. This
would add some overhead to IO​::File (likely a -d) to the constructor
for IO​::File.

* Do we want to document this behavior? Those who have bounced around
several POSIX environments have experienced this before and have
learned to deal with this behavior. Does this deserve mention on
IO​::File's Pod, or is a FAQ entry sufficient?

@p5pRT
Copy link
Author

p5pRT commented Sep 30, 2004

From @rgs

Steve Peters via RT wrote​:

OK, at least it seems that we're in agreement that this behavior is
operating system dependent and that we don't want to change it since it
could break things for Perl users on environments where an open() on a
directory works.

Yep.

Two points brought up remain, though.

* Do we want to add an optional argument to IO​::File->new() so that it
fails on an open attempt on a directory? The advantage of this would
be that it would allow for consistant cross-platform behavior. This
would add some overhead to IO​::File (likely a -d) to the constructor
for IO​::File.

I don't see how the current interface could be extended in a consistent,
elegant and backward-compatible way.

* Do we want to document this behavior? Those who have bounced around
several POSIX environments have experienced this before and have
learned to deal with this behavior. Does this deserve mention on
IO​::File's Pod, or is a FAQ entry sufficient?

Maybe a caveat in IO​::File. I'd say that this doesn't deserve a FAQ entry :)

--
A soft qualm, regret, flowed down his backbone, increasing. Will happen,
yes. Prevent. Useless​: can't move.
  -- Ulysses

@p5pRT
Copy link
Author

p5pRT commented Sep 30, 2004

From @petdance

On Thu, Sep 30, 2004 at 01​:26​:09PM -0000, Steve Peters via RT (perlbug-followup@​perl.org) wrote​:

* Do we want to document this behavior? Those who have bounced around
several POSIX environments have experienced this before and have
learned to deal with this behavior. Does this deserve mention on
IO​::File's Pod, or is a FAQ entry sufficient?

Just a note in the docs should be fine, I would think. We need to say
SOMETHING for those who don't realize that directory = file. Not
everyone is a Unix whiz.

xoxo,
Andy

--
Andy Lester => andy@​petdance.com => www.petdance.com => AIM​:petdance

@p5pRT
Copy link
Author

p5pRT commented Sep 30, 2004

From nick@ing-simmons.net

Andy Lester <andy@​petdance.com> writes​:

On Thu, Sep 30, 2004 at 01​:26​:09PM -0000, Steve Peters via RT (perlbug-followup@​perl.org) wrote​:

* Do we want to document this behavior? Those who have bounced around
several POSIX environments have experienced this before and have
learned to deal with this behavior. Does this deserve mention on
IO​::File's Pod, or is a FAQ entry sufficient?

Just a note in the docs should be fine, I would think. We need to say
SOMETHING for those who don't realize that directory = file. Not
everyone is a Unix whiz.

An alternative might be to fake open() to work on directories on Win32 ;-)

xoxo,
Andy

@p5pRT
Copy link
Author

p5pRT commented Sep 30, 2004

From nick@ing-simmons.net

Steve Peters via RT <perlbug-followup@​perl.org> writes​:

Two points brought up remain, though.

* Do we want to add an optional argument to IO​::File->new() so that it
fails on an open attempt on a directory? The advantage of this would
be that it would allow for consistant cross-platform behavior. This
would add some overhead to IO​::File (likely a -d) to the constructor
for IO​::File.

* Do we want to document this behavior? Those who have bounced around
several POSIX environments have experienced this before and have
learned to deal with this behavior. Does this deserve mention on
IO​::File's Pod, or is a FAQ entry sufficient?

Personally I see no reason to use IO​::File ever again so I don't care
what you do to it, or its POD.

I see some minor merit in mentioning amongst all the other
perldoc -f open stuff.
As for a FAQ entry, I don't remember this coming up
before and I have been on p5p for (9?!) years so this isn't
a very 'F' 'AQ'!

@p5pRT
Copy link
Author

p5pRT commented Nov 27, 2004

From @smpeters

[ni-s - Thu Sep 30 14​:34​:10 2004]​:

Steve Peters via RT <perlbug-followup@​perl.org> writes​:

Two points brought up remain, though.

* Do we want to add an optional argument to IO​::File->new() so that it
fails on an open attempt on a directory? The advantage of this would
be that it would allow for consistant cross-platform behavior. This
would add some overhead to IO​::File (likely a -d) to the constructor
for IO​::File.

* Do we want to document this behavior? Those who have bounced around
several POSIX environments have experienced this before and have
learned to deal with this behavior. Does this deserve mention on
IO​::File's Pod, or is a FAQ entry sufficient?

Personally I see no reason to use IO​::File ever again so I don't care
what you do to it, or its POD.

I see some minor merit in mentioning amongst all the other
perldoc -f open stuff.
As for a FAQ entry, I don't remember this coming up
before and I have been on p5p for (9?!) years so this isn't
a very 'F' 'AQ'!

Below is a patch to explain the behavior and to suggest better alternatives.

--- /usr/libdata/perl5/i386-openbsd/5.8.5/IO/File.pm Fri Sep 17
13​:09​:59 2004
+++ ./IO/File.pm Sat Nov 27 09​:32​:46 2004
@​@​ -95,12 +95,20 @​@​

=back

+=head1 NOTE
+
+Some operating systems may allow a C<IO​::File​::new> or C<IO​::File​::open>
+to be performed on a directory without errors. This behavior is not
+portable and not suggested for use. Instead, C<opendir> and C<readdir> or
+C<DirHandle> suggested instead.
+
=head1 SEE ALSO

L<perlfunc>,
L<perlop/"I/O Operators">,
L<IO​::Handle>
L<IO​::Seekable>
+L<DirHandle>

=head1 HISTORY

@​@​ -121,7 +129,7 @​@​

@​ISA = qw(IO​::Handle IO​::Seekable Exporter);

-$VERSION = "1.10";
+$VERSION = "1.11";

@​EXPORT = @​IO​::Seekable​::EXPORT;

@p5pRT
Copy link
Author

p5pRT commented Nov 27, 2004

From @smpeters

[stmpeters - Sat Nov 27 07​:36​:47 2004]​:

[ni-s - Thu Sep 30 14​:34​:10 2004]​:

Steve Peters via RT <perlbug-followup@​perl.org> writes​:

Two points brought up remain, though.

* Do we want to add an optional argument to IO​::File->new() so that it
fails on an open attempt on a directory? The advantage of this would
be that it would allow for consistant cross-platform behavior. This
would add some overhead to IO​::File (likely a -d) to the constructor
for IO​::File.

* Do we want to document this behavior? Those who have bounced around
several POSIX environments have experienced this before and have
learned to deal with this behavior. Does this deserve mention on
IO​::File's Pod, or is a FAQ entry sufficient?

Personally I see no reason to use IO​::File ever again so I don't care
what you do to it, or its POD.

I see some minor merit in mentioning amongst all the other
perldoc -f open stuff.
As for a FAQ entry, I don't remember this coming up
before and I have been on p5p for (9?!) years so this isn't
a very 'F' 'AQ'!

Below is a patch to explain the behavior and to suggest better
alternatives.

--- /usr/libdata/perl5/i386-openbsd/5.8.5/IO/File.pm Fri Sep 17
13​:09​:59 2004
+++ ./IO/File.pm Sat Nov 27 09​:32​:46 2004
@​@​ -95,12 +95,20 @​@​

=back

+=head1 NOTE
+
+Some operating systems may allow a C<IO​::File​::new> or C<IO​::File​::open>
+to be performed on a directory without errors. This behavior is not
+portable and not suggested for use. Instead, C<opendir> and
C<readdir> or
+C<DirHandle> suggested instead.
+
...

Scratch the previous patch as I noticed a grammatical error right after
sending it off. Use the below patch instead.

--- /usr/libdata/perl5/i386-openbsd/5.8.5/IO/File.pm Fri Sep 17
13​:09​:59 2004
+++ ./IO/File.pm Sat Nov 27 09​:38​:21 2004
@​@​ -95,12 +95,20 @​@​

=back

+=head1 NOTE
+
+Some operating systems may allow a C<IO​::File​::new> or C<IO​::File​::open>
+to be performed on a directory without errors. This behavior is not
+portable and not suggested for use. Instead, C<opendir> and C<readdir> or
+C<DirHandle> are suggested instead.
+
=head1 SEE ALSO

L<perlfunc>,
L<perlop/"I/O Operators">,
L<IO​::Handle>
L<IO​::Seekable>
+L<DirHandle>

=head1 HISTORY

@​@​ -121,7 +129,7 @​@​

@​ISA = qw(IO​::Handle IO​::Seekable Exporter);

-$VERSION = "1.10";
+$VERSION = "1.11";

@​EXPORT = @​IO​::Seekable​::EXPORT;

@p5pRT
Copy link
Author

p5pRT commented Nov 27, 2004

From @petdance

On Sat, Nov 27, 2004 at 03​:36​:48PM -0000, Steve Peters via RT (perlbug-followup@​perl.org) wrote​:

+Some operating systems may allow a C<IO​::File​::new> or C<IO​::File​::open>
+to be performed on a directory without errors. This behavior is not
+portable and not suggested for use. Instead, C<opendir> and C<readdir> or
+C<DirHandle> suggested instead.

Let's ditch the passive voice and be more definitive.

Some operatings systems may perform a C<IO​::File​::new> or
C<IO​::File​::open> without errors. This behavior returns raw information
about the directory, and is not portable. Instead, use C<opendir> and
C<readdir> or the C<DirHandle> module.

Thanks for digging this up again.

xoa

--
Andy Lester => andy@​petdance.com => www.petdance.com => AIM​:petdance

@p5pRT
Copy link
Author

p5pRT commented Nov 27, 2004

From @smpeters

On Sat, Nov 27, 2004 at 10​:55​:39AM -0600, Andy Lester wrote​:

On Sat, Nov 27, 2004 at 03​:36​:48PM -0000, Steve Peters via RT (perlbug-followup@​perl.org) wrote​:

+Some operating systems may allow a C<IO​::File​::new> or C<IO​::File​::open>
+to be performed on a directory without errors. This behavior is not
+portable and not suggested for use. Instead, C<opendir> and C<readdir> or
+C<DirHandle> suggested instead.

Let's ditch the passive voice and be more definitive.

Some operatings systems may perform a C<IO​::File​::new> or
C<IO​::File​::open> without errors. This behavior returns raw information
about the directory, and is not portable. Instead, use C<opendir> and
C<readdir> or the C<DirHandle> module.

Thanks for digging this up again.

xoa

Better still, let's mention directories earlier...

Some operatings systems may perform a C<IO​::File​::new> or
C<IO​::File​::open> on directories without errors. This behavior returns raw
information about the directory, and is not portable. Instead, use
C<opendir> and C<readdir> or the C<DirHandle> module.

Steve Peters
steve@​fisharerojo.org
 

@p5pRT
Copy link
Author

p5pRT commented Nov 28, 2004

From @ysth

On Sat, Nov 27, 2004 at 11​:20​:28AM -0600, steve@​fisharerojo.org wrote​:

On Sat, Nov 27, 2004 at 10​:55​:39AM -0600, Andy Lester wrote​:

On Sat, Nov 27, 2004 at 03​:36​:48PM -0000, Steve Peters via RT (perlbug-followup@​perl.org) wrote​:

+Some operating systems may allow a C<IO​::File​::new> or C<IO​::File​::open>
+to be performed on a directory without errors. This behavior is not
+portable and not suggested for use. Instead, C<opendir> and C<readdir> or
+C<DirHandle> suggested instead.

Let's ditch the passive voice and be more definitive.

Some operatings systems may perform a C<IO​::File​::new> or
C<IO​::File​::open> without errors. This behavior returns raw information
about the directory, and is not portable. Instead, use C<opendir> and
C<readdir> or the C<DirHandle> module.

Thanks for digging this up again.

xoa

Better still, let's mention directories earlier...

Some operatings systems may perform a C<IO​::File​::new> or
C<IO​::File​::open> on directories without errors. This behavior returns raw
information about the directory, and is not portable. Instead, use
C<opendir> and C<readdir> or the C<DirHandle> module.

But that's not correct; I thought some allowed opening directories but
always return eof. The vague "not portable" is much better than
making promises about what will be returned if the open succeeds. And
I'd keep it in the family by recommending IO​::Dir rather than
DirHandle. (DirHandle doesn't provides seek and tell; IO​::Dir does,
as well as the weird tie interface that I can't imagine ever using.)

@p5pRT
Copy link
Author

p5pRT commented Feb 1, 2005

From @smpeters

[ysth - Sat Nov 27 19​:23​:58 2004]​:

On Sat, Nov 27, 2004 at 11​:20​:28AM -0600, steve@​fisharerojo.org wrote​:

On Sat, Nov 27, 2004 at 10​:55​:39AM -0600, Andy Lester wrote​:

On Sat, Nov 27, 2004 at 03​:36​:48PM -0000, Steve Peters via RT
(perlbug-followup@​perl.org) wrote​:

+Some operating systems may allow a C<IO​::File​::new> or
C<IO​::File​::open>
+to be performed on a directory without errors. This behavior
is not
+portable and not suggested for use. Instead, C<opendir> and
C<readdir> or
+C<DirHandle> suggested instead.

Let's ditch the passive voice and be more definitive.

Some operatings systems may perform a C<IO​::File​::new> or
C<IO​::File​::open> without errors. This behavior returns raw
information
about the directory, and is not portable. Instead, use C<opendir>
and
C<readdir> or the C<DirHandle> module.

Thanks for digging this up again.

xoa

Better still, let's mention directories earlier...

Some operatings systems may perform a C<IO​::File​::new> or
C<IO​::File​::open> on directories without errors. This behavior
returns raw
information about the directory, and is not portable. Instead, use
C<opendir> and C<readdir> or the C<DirHandle> module.

But that's not correct; I thought some allowed opening directories but
always return eof. The vague "not portable" is much better than
making promises about what will be returned if the open succeeds. And
I'd keep it in the family by recommending IO​::Dir rather than
DirHandle. (DirHandle doesn't provides seek and tell; IO​::Dir does,
as well as the weird tie interface that I can't imagine ever using.)

OK, the passive voice has ben removed, vague results restored, and IO​::Dir suggested
instead. An updated patch is attached.

@p5pRT
Copy link
Author

p5pRT commented Feb 1, 2005

From @smpeters

IO.diff

@p5pRT
Copy link
Author

p5pRT commented Feb 17, 2005

@rgs - Status changed from 'open' to 'resolved'

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