Reply to thread

Message: [QUOTE="robic0, post: 4803290"] This has nothing to to with specifications. Its not a what if game its accident prevention. Anything involving a loop controlled by a counter should never have a single breakout value especially when it grows a variable in each pass. Unless it is absolutely known that this condition will occurr every time, it should not be done. until (tr/\n/\n/ == 8); will hang the program if the number of newlines in the record are 7 or more (you add 1, pluss the eor pickup). Looking at the randomness of the OPs data sample makes this extremely likely to happen. Single line white spaced characters don't count as \n\n eor in this case $/="". Its obvious his data is poorly generated and unformatted so he will miss some labels because of garbled information. BUT thats no reason to NOT throw in a RANGE check in the loop so the machine doesn't crash is it? Yeah, he didn't say "I don't want my fucking machine to crash!", but I'm just taking a wild assed guess he doesn't. The OP sounds like he doesn't wan't his printer to "bomb" when printing labels. Adding a few lines of error checking will not only prevent the OS from crashing (so then he can feel comfortible using the program in batch mode) but flag the rejects to a file to be fixed later. I don't think that the OP is looking for a speed label printer. I also don't like the use of $/="" here given that the natural eor is \n in this case, and without parametric checking you have made the looping dependent upon an exact count of CRLFs contained in the data record, a record that is obviously flawwed, that has NO guarantee to contain anything. If the data weren't flawwed and he could control it, he would already have done it when the data was generated, why would he need a Perl program? Theres no guarantee of "\n\n" using $/="", it only takes 7 sequential ^\n/newline to send this code into a loop that expands $_, 100k/second until the OS crashes. Might as well have: $cnt = 9; while(1) { last if ($cnt == 8); $_ .= "\n"; $cnt++; } When trying to format ascii/unicode text from a file, you can't rely on anything in that file to be in a guaranteed order or contain guaranteed text. Triggers can be used to line up a frame. This positively cannot be done by the use of counting newlines or blank lines as the sole mechanism. So basically I would not recommend this method at all. There's nothing about it that would inspire confidence if this were production code. If the DATA file is consistent in its formation and only sometimes jerky in known intervals and the OP just wanted a 1-time squirt to print some labels, then yeah, the code is about as primative and raw a method as you can use. No matter what the usage, ">=" aviods a nasty out of memory crash that could corrupt open files (filesystem), registry, etc.. For this reason, I would "overrule" the design specifications, ("==") or suggest he find someone else that has liability insurance for these cases. [/QUOTE]

Verification