in reply to substr in nested foreach loop
You didn't show enough code & data to be able to say for sure. But one thing occurs to me: Perhaps you've got blank lines in @plines, so you're asking for characters after the end? Try inserting the following line as the first line in your inner loop to check:
print '"',$pline,'": len=',length($pline),"\n";
--roboticus
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Re^2: substr in nested foreach loop
by sarani (Sexton) on May 22, 2006 at 12:15 UTC | |
There are no blank lines anywhere in the data file. The lenght reads as 57, and the last substr asks for 8 chars after the offset,48 - that's 56. So no char after the end, unless my basic math is wrong.(Right?) If you'd like to see the entire code, I can put it up... UPDATEIt's up on my scratchpad. | [reply] |
|
Re^2: substr in nested foreach loop
by sarani (Sexton) on May 22, 2006 at 12:53 UTC | |
| [reply] [d/l] |
by Crackers2 (Parson) on May 22, 2006 at 15:40 UTC | |
Not directly related to your issue, but some comments anyway, in no particular order:
is the same as
Also,
probably doesn't do what you think. $FILE1 is not the same as the FILE1 you use in your open statement. Either change all places where you use a bare FILE1 to $FILE1 (which would make it a lexical filehandle), or just remove the my $FILE1; declaration. In your open call, you don't have to put quotes around the filename. It is however a good idea to use the three-argument form of open, in case someone tries to use something like >datafile as filename and causes you to overwrite the data file that way. So instead of
use something like
In your read subroutine, you're using the variable $a without declaring it. With almost any other name this would have caused a compile time error, but $a and $b are special. For that reason, it's best to avoid using either of those names. $xh, $yh, $zh, $x1, $y1, $z1, $i, $r and $r2 are only used within your dist subroutine, so you should only declare them in there, and not at the global level read is also the name of a built-in function, so it's usually better to avoid using it for any of your own functions unless you explicitely want to override it Your shebang line is showing /root/bin/perl as the path to perl. Since /root is usually only accessible by root, this means that you're developing and testing this code as root, which is generally not recommended. The use subs; is useless here as far as I can tell. Since the two file reads are really unrelated, you can reuse the same filehandle for both of them Making the changes above, the code looks something like this:
This code can stil be further improved, but it should be a nice step in the right direction. | [reply] [d/l] [select] |
by sarani (Sexton) on May 23, 2006 at 03:54 UTC | |
| [reply] |
by suaveant (Parson) on May 22, 2006 at 14:39 UTC | |
before the substr that's dying, just to be sure, maybe even print the line. But the main reason I write is to suggest using one unpack instead of three substrs... syntax would be (approximately, not tested) Pretty sure that would be more efficient. | [reply] [d/l] [select] |