On Wed, Jan 28, 2009 at 10:30 AM, Nicholas Clark <nick@ccl4.org> wrote: > On Sat, Jan 24, 2009 at 11:11:08PM -0500, Charles Bailey wrote: > >> - Moves the permission-changing code to File::Copy::cp(), making it >> non-identical to File::Copy::copy(). I think this is a decent >> compromise, retaining backwards compatibility in the "primary" >> routine, while allowing people who chose cp() to get more POSIXy >> semantics. It does break backwards compatibility of cp() wrt >> permissions. I can find a handful of examples in CPAN, for which I >> hope smokers will give some feedback. As for the DARKpan, who knows . >> . . > > Although it's starting to sound like this should be in syscopy, not cp. > syscopy is currently documented as > > File::Copy also provides the C<syscopy> routine, which copies the > file specified in the first parameter to the file specified in the > second parameter, preserving OS-specific attributes and file > structure. For Unix systems, this is equivalent to the simple > C<copy> routine, which doesn't preserve OS-specific attributes. For > VMS systems, this calls the C<rmscopy> routine (see below). For OS/2 > systems, this calls the C<syscopy> XSUB directly. For Win32 systems, > this calls C<Win32::CopyFile>. > > > Removing the "For Unix systems..." seems to be the least backwards > incompatible change of all proposed so far. syscopy() gets tricky, since it exists (or at least I wrote it) primarily for cases that can't be handled well within Perl. Do you think it'd be better to make syscopy() behave like cp() rather than copy() on Unix systems specifically? Would the idea be to leave cp() as is (like 5.8.9) and push the POSIXy stuff into syscopy()? That has a certain appeal insofar as the permission-changing is a specific OS-level solution. OTOH, it could be difficult to have syscopy() on non-Unix systems do the same thing, so using syscopy() would not portably guarantee a particular set of permissions. -- Regards, Charles Bailey Lists: bailey _dot_ charles _at_ gmail _dot_ com Other: bailey _at_ newman _dot_ upenn _dot_ eduThread Previous | Thread Next