Whoa. There is so much about your post that is incomprehensible (and
so much of it) that it's hard to figure out where to start. I'll try an unordered list...
- It's not at all clear what is meant by "works" vs. "doesn't work" -- what are you trying to accomplish given the "two parts" of sample input data?
- You appear to be using two input files, but you only provide sample data from one of them. (I think it's from "25jun2.kat2", not from "rnk_25jun_signif_.dst")
- You appear to be reading the first input file into an array, then writing that array out to a temp file, adding lots of meaningless lines to the data ("*\n*\n..."), then you read that temp file back into a second array, process the array in this horrible "for" loop, write stuff to a second temp file, and finally read that back into a third array in order to print stuff to a final(?) "half.kat" file. (This all seems inconceivably pointless -- you should be able to accomplish your goal, whatever it is, in a single pass over the data.)
- You seem to be opening and reading all of the "dist" input file on every iteration of the "for" loop over the lines from that first temp file. (Most people would read the second file into memory just once and store it in an array or something.)
- You have copied/pasted some massive "if ... elsif ... else ..." block numerous times, with just minor differences between the copies, making the code at least 10 times longer and more complicated than it should be. (Most people figure out how to use a loop or subroutine to eliminate redundant code.) Update: looking closer, I see you have two nested layers of copied if/elsif/.../else blocks, causing a geometric expansion of redundant code (aarrgghh!)
- You appear to be trying to "parse" the data by counting lines (offsets in the arrays), where most people would do true parsing, which means reading the data into a structure (array or hash containing arrays or hashes) that respects/represents the bracketing of information provided by the data.
- Your posting of the code appears to have lots of spurious, errorful whitespace (inserted in the middle of variable names, etc.)
There are some "stylistic issues" too, but no point going into that, given the issues above.
So how about you start over with first principles: you've given a sample of one of the "original" input files, so how about you give (a) a sample of the other input, (b) the intended output, and (c) a brief summary of the criteria and relations that cause the output to be what it is. Think of that summary in terms of a synopsis or a minimal recipe -- that is, think about how you would document this process, how you would provide an overview of what the program is supposed to do. (My rule: write the docs/specs first, well enough that someone else can understand them, before writing any code.)
Forget about the code you've posted -- it's entirely wrong and it should be deleted. Write the concise description of what your process must do in terms of the input, the output and the logic that relates these two. Then start writing the code from scratch to address that description (or start a new SoPW thread with a question about how to approach that task).