in reply to Re^2: maximum number of lines for negative lookahead assertion (?!)
in thread maximum number of lines for negative lookahead assertion (?!)

what does the variable $line catch? there are two parathes besides the non-capturing one. From the output it's the number of lines, is that what the /g does? then why need the while?
  • Comment on Re^3: maximum number of lines for negative lookahead assertion (?!)

Replies are listed 'Best First'.
Re^4: maximum number of lines for negative lookahead assertion (?!)
by ikegami (Patriarch) on May 04, 2005 at 03:20 UTC

    Keep in mind this is a simplification of his actual code, with extra code added for debugging. He followed proper PM etiquette by posting the miminum code which causes the problem, whether the code itself makes sense or not on its own.

    For example, the /g is useless in this example, since $line will always be matched in its entirety. In the real program, he would have something different in the body of the inner while.

    The captures are also nonsense. The regexp should read
    /^>(.*)\n((?:^(?!>).*\n)+)/gm
    instead of
    /^(>.*)\n(^(?!>).*\n)+/gm
    if he wishes to capture anything.

Re^4: maximum number of lines for negative lookahead assertion (?!)
by tlm (Prior) on May 04, 2005 at 02:47 UTC

    $line is not catching anything; it is the string the match is being done on. The captures are not being used in this case; one would get the same results if the capture parentheses were replaced with (?:...)s.

    the lowliest monk

      you're right. I should have read it more carefully, but I did stare at it for a long time, somehow in my mind $line was something else, oh well.
        The code is adapted from Chapter 10 of the book Beginning Perl for Bioinformatics (http://examples.oreilly.com/begperlbio/) and it parses the alignments in BLAST (http://www.ncbi.nlm.nih.gov/BLAST/) results.

        Paul