Lemme guess...
There are other bugs that I can see potentially being an issue as well. But this is the most obvious one. | [reply] |
Nice bug. It took some time for me to realize it.
First I thought that chomp can't remove the multi-character suffix. But it can. The real bug is
| [reply]
[d/l]
[select] |
use strict;
use warnings;
# my $file = shift || die "No file, dummy!";
# open FH, "<", $file or die "Could not open ($file) for reading: $
+!";
local $/ = "\n.\n";
while (defined (my $record = <DATA>)) {
chomp $record;
print $record;
# <STDIN>;
}
__DATA__
sdjh
sfhg
srig
srgsrigh
.
.
.
asdigf
wsergh
This gives:
sdjh
sfhg
srig
srgsrigh.asdigf
wsergh
A . was left there unremoved, if that's the bug you are looking for (As it cannot handle empty record.) | [reply]
[d/l]
[select] |
For enlightenment, uncomment the code that you commented out one line at a time until the bug rears its ugly head.
| [reply] |
The other thing is that <STDIN>. It does not return in the normal way, which is expected base on the code, as line break has been reset to "\n.\n". But you can easily get around by entering "\n.\n" (<Enter>.<Enter>) to continue and inspect the next record.
Any way, my first reply still reveals a bug, if the program is required to handle empty record.
| [reply] |
| [reply] |
To be frank, it is quite unfair to ask people to guess that one bug you stumbled on, when there are quite a few other bugs exist, as other monks have already pointed out.
I believe that you were stuck for a while with that <STDIN> as pg and tilly has pointed out, but that was just the one bug that was obvious...
| [reply] |
Wasn't particularly trying to be difficult. I should have mentioned that I had a guaranteed file format. The <STDIN> issue is the only in that code which I can think of which pretty much has to be a bug (in that it violates expectations, even though it's doing what I asked). Of course, some would argue that perhaps one would intend that they be able to type a "." to continue and thus it's not a bug, but that would be getting pedantic, I think.
| [reply] |
#!/usr/bin/perl
use strict;
use warnings;
use English;
my $file = shift || die "No file, dummy!";
open FH, "<", $file or die "Could not open ($file) for reading: $!";
local $INPUT_RECORD_SEPARATOR = "\n.\n";
while (defined (my $record = <FH>)) {
chomp $record;
print $record;
<STDIN>;
}
I probably would have spotted it a lot faster. So maybe the "best practices" moral here would be to use English when doing this kind of magic thing. Even if you're a perlvar wiz, the guy maintaining your code may not be.
The second moral of the story is, with regards to finding versus spotting: if you've got a short little chunk of code like this and you know it's got a bug in it, read through every line. Read the first line. Think about it. Read the next line. Think about it. Until you've read every line. Seems like an obvious thing to do, but I am not in the habit of doing it. I am in the habit of write, try it out, check for bugs. I don't usually write then check for bugs.
But of the two morals, I think use English would probably save more time in the grand scheme of things. I may put this on my list of best practices now for everything other than $_. (I wonder whether damian conway mentioned the subject in his book?) | [reply]
[d/l] |