Nick Ing-Simmons wrote : || John Macdonald <jmm@elegant.com> writes: || >Nick Ing-Simmons wrote : || >|| John Macdonald <jmm@elegant.com> writes: || >|| >|| || >|| >|| That is far from daft. sv_gets() (the internals of readline) would know || >|| >|| what it had used to find the end of the line. It could leave the || >|| >|| information around for chomp to use. || >|| > || >|| >But as soon as you have a program that opens multiple files of || >|| >differing formats, this breaks down. You end up with taint-like || >|| >tracing of strings to track which form of file each string came || >|| >from. || >|| || >|| Yes, the EOLN string would have to be annotated on the SV somewhere || >|| presumably as "magic". Having chomp look for "EOLN magic" on the SV || >|| would be easy to do. The 'set' part of the magic would clear the field. || > || >It gets messier... || > || > $para = "$file1_lines$file2_lines$file3_lines"; || > || >Which of the three EOLN magics gets assigned to $para? || || In my purely fictional implementation none would. so then: chomp $file3_lines; chomp $para; could remove different values from two strings with the same termination value originating from the same source file line, which would violate the principle of least astonishment for some users. Good thing this whole issue is fictional. :-) -- objects: | John Macdonald Think of them as data with an attitude. | jmm@elegant.comThread Previous | Thread Next