Front page | perl.perl5.porters |
Postings from November 1999
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?
|| >Which means that...
|| >
|| >|| But the "right thing" is
|| >|| just to return \n as a logical newline however it was represented in the
|| >|| buffer (unless in binmode of course). Then chomp'ing \n is fine.
|| >
|| >is really a much better choice.
||
|| I know ;-) I am delinquent in implementing it.
||
|| >That just leaves the issue of
|| >determining the right filtering to do for an output file so that
|| >it matches the input file it is derived from or the target it is
|| >being written to or whatever is the most significant issue -
|| >which the programmer will have to deal with.
--
objects: | John Macdonald
Think of them as data with an attitude. | jmm@elegant.com
Thread Previous
|
Thread Next