On Tue, Dec 7, 2010 at 2:21 PM, Rob Dixon <rob.di...@gmx.com> wrote: > On 07/12/2010 09:24, Jonathan Pool wrote: > >> >> Are you familiar with the perl debugger? >>> >> >> Thanks much for your reply. I haven't used the debugger, partly >> because its documentation describes it as an interactive tool and >> it's not clear to me how that works in my context. The script is >> executed by httpd in response to a browser form submission, which >> includes a file upload. >> >> Alternatively you could take a look at the Tie::Watch module to do >>> asimilar thing without using the debugger. >>> >> >> I could look into using this. On the other hand, to get access to >> the variable's value one can use "warn" to write to the error log, and >> yet >> that blocks the problem from occurring, so I can imagine that any other >> method that reads the value and writes it somewhere will do the same. >> >> I would like to see the Perl source to be able to be more helpful >>> to you. >>> >> >> The current script where the error occurs is at >> >> >> http://panlex.svn.sourceforge.net/viewvc/panlex/perl/plxu.cgi?revision=27&view=markup >> >> The error occurs at line 1297. >> > > So the line in question is > > @res = (split /\n\n/, ($in{res} = (&NmlML ($in{res}))), -1); > > and, although I can see no proper reason why it should make any difference > in this case, I recommend removing the ampersand from the function call: it > is bad practice in anything but very old Perl. I would also prefer to lose a > few parentheses, purely for the sake of readability. So please try this: > > @res = split(/\n\n/, $in{res} = NmlML($in{res}), -1); > > Cheers, > > Rob > > > -- > To unsubscribe, e-mail: beginners-unsubscr...@perl.org > For additional commands, e-mail: beginners-h...@perl.org > http://learn.perl.org/ > > > Hi Jonathan,
I have had situation with a very old perl (5.4 or something like that) where on a certain line I would get an error thrown every single time, but if I added a few lines to the script even empty lines the error would not occur at all no mater what the data was that I put in. This was in combination with Apache httpd, since the whole thing was hosted with the cheapest web host available on the web at the time I dismissed this as a error in their setup and didn't bother figuring it out. I mean if a few empty lines can resolve the problem why bother spending a lot of time on identifying a seemingly random error. At the time I was fairly new to perl and was quite sure that my lack of knowledge was the thing that caused the problem in the first place but now that I see your problem description I am not so sure anymore... who knows there might be certain cases where perl + apache + certain commands in certain combinations cause these inexplicable problems to occur. Could you just for fun add a few empty lines (say 50 or so) just before the line 1297 and see if you then get the same error on line 1347? If not then your problem is 100% identical to the problem I was facing several years ago and maybe just maybe it was not my lack of perl knowledge or the bad hosting provider that was at fault. The biggest problem I have with CGI scripts is that they are so hard to debug, it really comes down to pushing data to the error log or some other file you are using to keep track of what is going on in the application, but simply stepping trough the script and seeing where the problem comes from is not an option which I feel is a really big gap in a developers options to properly resolve reported bug in an application. Regards, Rob
