DJ Stunks (
[email protected]) wrote on MMMMDCXXXV September MCMXCIII in
<URL://
// Abigail wrote:
// > Ben Morrow (
[email protected]) wrote on MMMMDCXXXV September MCMXCIII
// > in <URL:// > {}
// > {} You do not need to use mv(1) for this; see File::Copy, or indeed just
// > {} rename in perlfunc.
// >
// >
// > File::Copy is utterly broken, and has extremely limited capabilities
// > compared to the utilities it's supposed to be an alternative for.
// >
// > I wouldn't touch File::Copy with a 10 feet pole.
// >
// > I'd use 'rename' if and only if I'm sure both the source and the
// > destination are files in the same filesystem - otherwise I would use
// > 'system mv'. And I rather write a Java program moving the file for me
// > then have File::Copy screw up.
// >
// > Friends don't let friend use File::Copy.
//
// well, that's quite an odd thing to say, particularly as it comes from
// someone who has and does contribute to Perl. Therefore, I feel a bit
// like I'm preaching to the choir, but the whole crux of the open source
// community is to feed back and resolve bugs... In addition, counselling
// thousands of people to roll their own copy() subroutine invalidates the
// whole theory behind the CPAN archive.
//
// So I would humbly suggest that if File::Copy really is broken (and I'd
// be quite surprised if it is since 1) it's a standard module, and 2)
// I've used it without issue in production) that you submit a bug report
// (at minimum) or a bug report and it's corresponding bugfix.
//
Please do your homework.
I've submitted the bug report.
Years ago.
And a few times a year, I rant about its brokenness. Noone seems to care
(but oh by god, people do care if you ignore a broken Perl module and
call something from a working toolbox - after all, most Perl programmers
that are active in forums are religious nuts)
In 2003, for instance, in this very forum:
<
[email protected]>
Or in a thread in 2004: <
[email protected]>
And if you have the stomach to visit perlmonks, you'll find posts by
me pointing out the brokenness of File::Copy.
Don't tell me I didn't warn "the community" - I've been doing so for years.
Here's a program that shows the brokenness of File::Copy::copy (move
suffers from the same problem if it needs to do a copy & delete action).
#!/usr/bin/perl
use strict;
use warnings;
no warnings 'syntax';
use File::Copy;
my ($src, $dest1, $dest2) = ("/tmp/src", "/tmp/dest1", "/tmp/dest2");
for my $file ($src, $dest1, $dest2) {
die "$file exists, not running this test\n" if -f $file;
}
umask 022 or die "umask: $!\n";
open my $fh => ">", $src or die "open: $!\n";
close $fh or die "close: $!\n";
chmod 0755 => $src or die "chmod: $!\n";
copy $src => $dest1 or die "copy: $!\n";
system cp => $src, $dest2 and die "cp: $?\n";
my $d1_perm = ((stat $dest1) [2]) & 07777;
my $d2_perm = ((stat $dest2) [2]) & 07777;
if ($d1_perm == $d2_perm) {
print "Permissions equal\n";
}
else {
die sprintf "Expected permissions %3o, got permissions %3o\n"
=> $d2_perm, $d1_perm;
}
__END__
Running the program gives:
Expected permissions 755, got permissions 644
Losing your execute bits when copying files means the module is broken.
// Finally, I would also suggest re-reading _The Cathedral and the Bazaar_
// to brush up on the notion that, as Linus once famously said, "Given
// enough eyes, all bugs are shallow."
Linus is wrong. Fixing bugs needs _tuits_, not eyes. Furthermore, more
thatn 99% of the users of an open source product will never look at the
code.
Abigail
arseExcel to read Excel files and