use IO::All;

my $buffer = <<EOS;

    Here there be dragons!
EOS

io("foo.txt") < $buffer;
[download]

So it is arguably doing the right thing and they are not bugs, at least not bugs in the binary but in the dox somewhere. As mentioned there, they don't actually exist. At least, such an argument could be made for sys*. Stat ought to be able to fake most things for a scalar easily enough, although one could argue sys* aren't that hard either. It's either a gross oversight on somebody's part, or a big can of worms they decided to consider Somebody Else's Problem.

--
I'm not belgian but I play one on TV. On dit que je parle comme un belge aussi.

They aren't bugs in implementation, but in specification. This is why you need requirements and design reviews along with code reviews.

---

The Perfect is the Enemy of the Good.

Not really an answer to your question -- I don't have one -- but some alternative code:

#!/usr/bin/perl

use strict;
use warnings;
use File::Copy;

my $buffer = <<EOS;

    Here there be dragons!
EOS

open my $fh, '>', 'foo.txt';

print $fh $buffer;
[download]

This code is a simplified example. The real code is much bigger and more complex. And is used for everything from getting data from pipelines (open my $fh, "tar cf - * | gzip -c |";) carrying hundreds of MB of data, to a couple KB of strings. The latter isn't a big deal, the former is. I'm figuring that I'm going to have to perform the copy myself. Not hard to do, but just has to be done. Note that I can't assume anything about the data, so if I want to be efficient (time/memory), I'm going to either have to use sysread or something, or I'm going to have to set $/ to \1024 or something (fixed length read/write, not line-by-line since, as potentially binary data, I don't have any idea what lines are). Not a big deal, but this is what I was using File::Copy for. :-)

I'm just going to rip some of it from File::Copy, and assume the filehandle is good. I do know, however, that the from-handle and the to-filename should not be the same (it would actually be difficult to do), so this should be ok for all but the pathological cases (where someone is simply trying to break something on purpose).

Thanks!

FWIW, fileno returns -1 for handles pointing to scalar refs, though this behavior appears to be undocumented; at least the docs for fileno are noncommittal on the subject.

Interesting, this code compiles and runs, but the data isn't copied.

#!/usr/bin/perl

use strict;
use warnings;
use File::Copy;

my $buffer = <<EOS;
    Here there be dragons!
EOS

copy(\$buffer, "foo.txt");
[download]

Update:

My bad. The Copy chokes on a non-filehandle.

Send a bug report to File::Copy author!.

Yeah ... I was hoping the PerlIO abstracted this, too ;-)

What would be really cool is to be able to do this:

{
  local *STDOUT;
  my $buf;
  open STDOUT, '>', \$buf;
  system("some_command","with","args");
  $logger->write($buf);
}
[download]

But that's probably expecting a bit much. ;-)

Anyway, as I said in the original post of the thread, I can't quite figure out who the author is - probably owned by p5p anyway. So I submitted the bug report - we'll see if there's any answer. I do still think, however, that this is a much larger problem than I would be able to give a reasonable patch for, since getting it to work properly may involve many, many changes, or just one: disallow string-handles in File::Copy.