On Thu, 26 Dec 2002 20:12:15 +0200, Jarkko Hietaniemi wrote: >The attached patch seems to work with my extremely limited testing >so that Perl scripts can be any of the LF, CRLF, or CR end-of-lined. >(Not that great a feat since the LF and CRLF have both worked already.) >(No, this patch doesn't do the mythical LFCR.) > >The new test script t/comp/eol.t is the extremely limited testing, >it tries to create a script in all the three EOLings, and parse and >execute it, and verify the results. I've only tried this in one UNIX >variant of the PerlIO_fast_gets() kind, so I can't really say that >I've tested much. > >Looking at the crux of the matter, Perl_sv_gets(), I notice both that >strange and wonderful lands like VMS and non-PerlIO_fast_gets() lands >might not be quite right yet. Furthermore, there might be more >parsing code changes needed in various places (mostly toke.c, >probably) like the changes I needed to make to format parsing. > >An additional doubt I have whether my changes slowed down, err, >quieted down, the screaming of Perl_sv_gets() too much. That is, >does my extra logic slow down reading in scripts too much. > >Of course, the ultimate acid test will be whether this patch really >works in Mac OS Classic (CR) and whether the patch didn't broke Win32 (CRLF). I think the last time we spoke of this the rough consensus was to do it as a layer that is pushed only on PL_rsfp. Internally, perl should deal with just a logical newline (we can arbitrarily decide it to be ASCII LF to match the most sane of the three universes). All of the translation will then happen during the reading of the source file, and internally perl should just see '\n' where it is looking to deal with a newline (in all three universes, given any of the three types of source files). IMHO, dealing with non-native forms of newline for data (non-source) filehandles should be strictly at the discretion of the user. They can push a layer to get the functionality. Sarathy gsar@ActiveState.comThread Previous | Thread Next