Your description of the problem is too confusing (confused). What/where is this "html file" that has these comment tags like "<!-- 2 -- > and so forth"? Why are you using a format that is not really XML or HTML (or XHTML)? What does a client/user supply? What does the client/user want in response?
Get down to first principles. Break things up into individual, modular components that do specific, simple parts of the task. Plug these components into subroutine calls in loops as needed, and make the code look like a natural-language description of the task. (I gather that English is not your first language, whereas it tends to be the first natural language for perl; this might be a problem, but sticking to simple "command-style" statements ("do this, then do that, then...") will serve you well enough.
Separate the creation/management of data structure from the presentation of data, and set up a main-level controller that uses those two sets of functions ("model vs. view vs. control"). Based on what you've shown so far, I don't think there's anything else I can offer. | [reply] [d/l] |
What if I simplify or complicated my question where the end results on the tag numbers instead of duplicating they would increase, can this be done? What do you think?
<1>66543
<2>2009
<3>TY
<4>-
<6>
<7>TOM
<8>2 - DUNDAS
<8>100 - MAIN
<9>ONT 00001
<10>
<11>000-000-0000
<12>
<13>12345
<14>1999
<15>PP
<16>XLX - TEST
<17>Comm
<18>
<19>1 BLVD
<20>MA 00001
<21>CITI, INC.
<22>000-000-0000
<23>
Thanks! | [reply] [d/l] |
What do you think?
I think that if you are still having trouble figuring this out on your own, and you want to get help from perlmonks, you should:
- Sign up for an actual user account, so that communication with other monks is easier and more efficient.
- Create a simple, small example / test case, including both some minimal amount of sample input data, and only as much perl code as needed to demonstrate what you are trying to do with the data.
- Post that code and data to a new "SoPW" thread, showing both the actual script output, and the desired script output, so we can see the difference.
The example / test case data and code should be fully self-contained, which means that the code should be runnable on its own with the given data, so that other monks can try it out for themselves if they feel like it.
And as I said previously: break the problems down and separate them into different subs and/or modules that focus on particular parts of the problem; that will help you organize your thoughts.
Good luck.
| [reply] |