Re: CDATA-like "literal" tags in XML-like data

[danger]

Well, rather than comment on the potential fragility in such parsing schemes, I'll suggest a simplification to your scan() routine (reducing the loc by half+):

sub scan ($) {
    my $line = shift;
    while ($line =~ m/<\s*(\w+)([^>]*)>/g) {
        next unless is_literal($1,$2);
        my $start   = pos($line);
        my $len     = index($line,"</$1>",$start) - $start;
        my $passage = \substr($line,$start,$len);
        $$passage   = escape_out($$passage);
        pos($line)  = $start;
    }
    print $line;
}

This uses assignment to pos() at the end of the loop to reset to where we left off so we may continue our match after modifying the string. Also, this uses a reference to the substr() function ... this is a reference to an Lvalue so assigning through the reference changes the substring being pointed to (perhaps a wee bit obfu for production use, but that's your decision :-)

Of course, if the data doesn't follow exactly according to your expectations (a closing </listing > tag for example won't be found because we didn't allow for a trailing space in the closing tag, nor did we check that index() found a closing tag, ...), then all bets are off for your preprocessor (OK, so I did make a fragility comment).

[John M. Dlugosz]

$passage = \substr

Yes, that's exactly what I was trying for. I seem to recall trying to do this before, but it didn't work. Maybe I never got the syntax right, or it wasn't right on earlier versions.

As for exactly following expectations, that's the point: it's all literal until a very strict end condition is reached. The <<EOF ... \nEOF construct is "fragile" too, as is forgetting to escape out a slash in a RE. Either follow the rules or get an error when things don't match up.

—John