> Tom Christiansen writes: > : >When I said, "I talked to" I meant that. I don't need the pointer - I know > : >how to handle it. But I wind up answering questions from people who do > : >not. In my experience most of them use chomp() so the confusion is > : >preventable. (After all you expect chomp() to get rid of line endings, > : >right?) > : > : I expect chomp() to remove one and only one terminating instance of the > : precise string to which $/ has been set; no more, no less. What were > : you expecting? I consider $/ the mechanism through which you can change "line ending" to "paragraph ending" etc... > I expect people to expect Perl to do the right thing. Ah yes, now I remember why I love this language. :-) The suggestion that I heard which I most like is letting $/ be an RE. So you can make $/ be /\n|\r\n?/ and it magically "does the right thing" on virtually any file. However integrating this logic into the RE engine could be interesting. After all if you apply the pattern I gave to a string that ends with \r, it will match even if the next character to be read is \n. This is manifestly not the right thing to do. :-( Ben PS Random note. A random idea a co-worker and I have been throwing around (based on my massively speeding up a program by doing this) is "lazy concatentation" of strings. If someone is building up a string through interpolation and concatentation, it makes sense to internally use something closer to an array of strings, and then join that into one string if you ever need to. (print() has no need to join them, the RE engine does.) This should transparently accelerate a lot of current Perl code...Thread Previous | Thread Next