Re: [FWP] Slurp weirdness

[Chip Turner <chip@zfx.com>]

"David L. Nicol" <david@kasey.umkc.edu> writes:

> Paolo Campanella wrote:
> > 
> > Paolo Campanella wrote:
> > 
> > > The 'split' must have crept in as one of a bunch of experiments I tried
> > > to nail down the problem, and forgot to remove - very un-fun :-(
> > 
> > Correction: the problem is only visible when using $/=undef and
> > splitting on newlines, as per my original post. When using the list
> > context, everything works as one would expect.
> 
> Sounds like you have uncovered a bug with the /proc file
> system. Have you explored the exact system calls, or at least
> mentioned this difficulty to a kernel developer? Which kernel are
> you using, for instance, and does the behavior go away on a
> different kernel?
> 
> Then again it could be perl; how does undefined-delimiter slurping work
> exactly?  There is no "read until eof" system call, all the system calls
> take some kind of length argument.  When you read the length of this
> /proc pseudo-file at a system call level, do you get the length of 63
> of its records?  If that is the case, whose problem is it?
> 
> The moral for now seems to be, "Don't use undefined slurps to read
> /proc pseudo-files"

I don't think it is a bug in the /proc filesystem.  Just like many
non-file descriptors that can be read with the read() system call, you
aren't guaranteed that you will get the whole file in one read.
Somewhat similar to a socket in that respect, I suppose.  It's
probably better to think of /proc as more like reading from sockets,
serial ports, or other non-file descriptors than reading from any old
normal file.

Whether it's a bug in perl or not is arguable.  For safety I would
slurp into an array context just to be sure.

Chip

-- 
Chip Turner                   chip@ZFx.com
                              ZFx, Inc.  www.zfx.com
                              PGP key available at wwwkeys.us.pgp.net

==== Want to unsubscribe from Fun With Perl?  Well, if you insist...
==== Send email to <fwp-request@technofile.org> with message _body_
====   unsubscribe