Front page | perl.perl5.porters |
Postings from June 2008
Re: [PATCH] File::Copy & permission bits.
Thread Previous
|
Thread Next
From:
Charles Bailey
Date:
June 8, 2008 19:11
Subject:
Re: [PATCH] File::Copy & permission bits.
Message ID:
b78749dd0806081911y1e7a2efawfcd4901605cec733@mail.gmail.com
On Sat, Jun 7, 2008 at 12:31 PM, <abigail@abigail.be> wrote:
> On Sat, Jun 07, 2008 at 11:44:02AM -0400, Charles Bailey wrote:
>
> [ .. Snip .. ]
>
>> In a nutshell, then, my thoughts on the current patch:
>> - The advantages in defaulting to POSIXy semantics don't outweight the
>> disadvantages of breaking backward compatibility. As Craig points
>> out, the breakage will be frequent in some environments.
>> - If we want to make extended semantics available, put them in
>> syscopy() or cp(), and break the identity on POSIXy systems between
>> these routines and copy(). I see that as less of a problem than
>> changing copy() because I think most programmers who chose to use
>> syscopy() or cp() are indicating their intention to use a particular
>> functionality. (This is less so for cp(), but I'd guess that most
>> people who choose this alias wouldn't be all that hurt if it behaved
>> like cp(1)).
>> - If the standard is not to break backwards compatibility at all, we
>> should implement new extensions in File::Copy::Foo, with clear
>> warnings in the docs that users of these platform-specific packages
>> should not expect their code to be portable.
>>
>> If there's a conensus that one of these alternate solutions is
>> appropriate and Abigail is too busy to update her change, I'm happy to
>> supply a patch to DTRT.
>
> As for the intention of File::Copy to replace "system cp $to $from",
> IMO, it has utterly failed, one of the reasons being it not respecting
> the permission bits of the origin. In fact, if I inherit code that
> uses File::Copy, I take my chainsaw, and replace its copy() calls with
> "system cp".
Good to know. It has been historically successful in meeting my
initial goal: allowing Perl to install itself and modules without
recourse to system(). I'm not really sure what the uptake of
platform-specific syscopy() has been; its initial goal was to
accommodate VMS- and Win32-specific file sructure.
If you (or anyone else reading) had a free hand to rewrite
Flle::Copy::cp(), is there anything besides copying permission bits
you'd want? Would it be worth thinking about timestamps, ownership,
links, something else as options?
> I'm also fine with leaving File::Copy not respecting permission bits
> at all. But then I'd like to see a clear warning in the documentation
> that File::Copy::copy isn't a replacement for "system cp", but behaves
> differently. And I'll keep ranting against anyway claiming I should
> favour File::Copy over "system cp".
Seems like more documentation is worthwhile, regardless of the
behavior that's finally chosen.
I guess we wait and see what consensus develops.
--
Regards,
Charles Bailey
Lists: bailey _dot_ charles _at_ gmail _dot_ com
Other: bailey _at_ newman _dot_ upenn _dot_ edu
Thread Previous
|
Thread Next