Front page | perl.perl5.porters |
Postings from June 2008
Re: [PATCH] File::Copy & permission bits.
Thread Previous
|
Thread Next
From:
Charles Bailey
Date:
June 7, 2008 08:44
Subject:
Re: [PATCH] File::Copy & permission bits.
Message ID:
b78749dd0806070844h35106873q8bb1216c79719592@mail.gmail.com
On Fri, May 23, 2008 at 11:53 AM, Craig A. Berry
<craig.a.berry@gmail.com> wrote:
>
> On Wed, May 7, 2008 at 4:16 PM, Abigail <abigail@abigail.be> wrote:
> >
> > The following patch to File::Copy makes if one copies a file, permission
> > bits are handled as POSIX 1003.1 describes the shell utility 'cp' ought
> > to behave.
>
> Belatedly following up on this. If the rationale is that Perl should
> act as much as possible like a native utility, then this clearly is
> the right thing to do. If, on the other hand, Perl should have its
> own definition of the right thing to do and act the same on all
> platforms, then this actually widens the gap between platforms. I
> don't have any strong objection to your change, but I just want you to
> be aware you are shifting us from the latter to the former (after
> umpteen years of the latter).
Even more belatedly following up, after several years away from p5p,
on this as well as last month's discussion of File::Copy. I agree
with Craig's assessment that this is a significant change. At a
minimum, I'd argue against it for backwards compatibility. But I
think there may be better ways to fold in the change as well.
For whatever value archaeology has, my intent when I worked on
File::Copy was to set up a two-layered approach. I thought -- and
think -- that copy() and move() should be defined in a fairly simple
and platform-agnostic way. Moving bytes from one place with a name to
another place with a name is all one needs for many tasks, and about
all one can expect to do in a portable way. (This does incorporate
the assumption that POSIX != portable, which I think is fair when
talking about basic operations.) Much of the practical motivation
here was to replace the C<system("cp $from $to")> in common use at the
time, both because not every platform calls its copy command "cp" and
not because every "cp" does the same thing.
Below this, there's the layer of platform/shell/spec/whatever-specific
functionality that I'd hope syscopy() would provide. The intent here
is that one would use syscopy() when one desired to replicate the
platform's extended notion of copying files, at the cost of
portability. (Again, this incorporates my assumption that the
portable way to copy a script looks more like C<copy($from,$to) &&
chmod($desired, $to)> (where $desired may well be C<(stat($from))[2]>)
than assuming POSIX semantics, which assumption isn't universal.)
As time has passed, I think a few changes in File::Copy's history have
muddied the waters somewhat:
* copy() and syscopy() have been the same thing under Unix. This
made some sense when I first set up syscopy(), since ACLs and extended
attributes weren't common, and weren't "expected behavior", but as
commonly used Unixy systems acquire the extended attributes like ACLs
that used to be limited to exotic systems, arguably this link should
be broken, and Unix syscopy() should become the home for POSIXy
permission semantics, attribute copying, et.
* cp() and mv() have been aliased to the basic copy() and move().
Again, this had more utility when the immediate goal was to persuade
programmers (and especially package makers, including the Perl core)
to migrate away from system() as the default means of copying simple
files. That's less of an issue now, and unintended implication that
the semantics of Perl's cp() and mv() precisely match those of
Unix/POSIX/Cygwin/OSX/whatever cp(1) and mv(1) has become more of an
issue. My thought is that the appropriate solution is to implement a
separate cp() (likely a call to copy() with after-copy fixups) that
matches POSIX semantics, perhaps with options, and do the same for
mv().
* The perceived role of File::Copy has flexed. The thread last month
referring to a conceptual difference between File::Copy and
File::Copydata highlighted this. I do think the difference isn't all
that great, and could be accommodated by appropriate changes at the
level of File::Copy::syscopy(), but it would also be possible to leave
File::Copy alone and create File::Copy::POSIX, FIle::Copy::Win32,
File::Copy::OSX, File::Copy::VMS, etc. I think this isn't a great
idea, but that's because I think most people don't _really_ need their
platform's full command-line semantics for most file copies, and most
cases where they need more than a simple copy are better handled by
writing copy-and-chmod or copy-and-utime rather than automatically
reaching for File::Copy::Foo and introducing incompatibilities. (That
doesn't apply to one-offs and home-use code in the way it does to
distributed code, an argument in favor of system-like copying routines
being available somewhere.)
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.
--
Regards,
Charles Bailey
Lists: bailey _dot_ charles _at_ gmail _dot_ com
Other: bailey _at_ newman _dot_ upenn _dot_ edu
Thread Previous
|
Thread Next