Front page | perl.perl5.porters |
Postings from June 2008
> On Mon, Jun 09, 2008 at 03:34:23PM +0200, Aristotle Pagaltzis wrote:
> My hope was that there were no effects at all for environments that
> don't have permissions bits, but I've no non-Unix environment to test
> that, nor any significant experience on non-Unix platforms to make any
> predictions, nor was perlport of any help of predicting the behaviour
> on non-Unix systems. (My thought was, if the platform doesn't have
> permissions, it doesn't really matter what the third argument of sysopen
> is).
Just about everybody has permission bits, but they do different things
with them. It's also filesystem-specific, not necessarily
OS-specific. Perl on a Stick may have to worry about these things if
those are FAT partitions on the data crystal. That's a good point
about perlport -- it ought to cover this better.
>> > I don't like the fact that copying from a handle now gives
>> > different behavior permissions-wise than copying from a
>> > filename, but that inconsistency could be ironed out pretty
>> > easily.
>
> I am surprised about this. My patch takes the permissions bit from the
> file handle (either the one passed to copy, or the one after opening
> the source file), and there are tests that check whether the permission
> bits are set correctly when copying from a file handle.
I believe you are correct about what your code does and how your tests
verify it. What I'm talking about is the case where your code will be
run when copying from a handle and an entirely different code path
(basically, the platform-specific syscopy) will be run when not
copying from a handle. This heavily patched section of code is where
the trouble is:
if (defined &syscopy && !$Syscopy_is_copy
&& !$to_a_handle
&& !($from_a_handle && $^O eq 'os2' ) # OS/2 cannot handle handles
&& !($from_a_handle && $^O eq 'mpeix') # and neither can MPE/iX.
&& !($from_a_handle && $^O eq 'MSWin32')
&& !($from_a_handle && $^O eq 'MacOS')
&& !($from_a_handle && $^O eq 'NetWare')
)
{
[big snip here]
return syscopy($from, $copy_to);
}
This heavily patched section of code almost (but not quite) means that
if we're not on Unix, use syscopy for everything because
$Syscopy_is_copy is false everywhere except on Unix. But if I'm
copying from a handle on any platform not in the list, I'll run your
new code instead of syscopy, which means I'll have potentially
different behavior than when I'm copying from a filename rather than
from a handle. VMS may be the only place where the behavior is likely
to have changed, and I could change it back by adding it to the list.
But the list has really gotten out of hand, and I wonder what the
logic should really be here. In a sense your patch has just added to
the list by different means, but rather than making a Unix-oriented
syscopy it's made the default copy into the Unix syscopy.
Thread Previous
|
Thread Next