If $frameworkcode and $op are not defined, it generates an error log entry. I confirmed that "|| q{}" was safe for $op, as there was only one place it was used. It is also safe for $frameworkcode, because it is impossible to enter nothing as a frameworkcode in biblio_framework. I checked back to biblio_framework because of the loop that does the "eq $frameworkcode" which floods the error log. The hashes are ultimately built from a select statement. This bug was discovered in 3.8.5, it applies to 3.6.x, 3.8.x, and master. Test Plan --------- 1) Login to staff client 2) Acquisitions 3) Search for a vendor (should exist) 4) enter a new basket (or existing basket) 5) "From an external source" 6) check error log file. There will be several errors like: [Sat Oct 06 20:09:37 2012] [error] [client 192.168.100.2] [Sat Oct 6 20:09:37 2012] z3950_search.pl: Use of uninitialized value $frameworkcode in string eq at /usr/share/koha/intranet/cgi-bin/acqui/z3950_search.pl line 100. And one like: [Sat Oct 06 20:09:37 2012] [error] [client 192.168.100.2] [Sat Oct 6 20:09:37 2012] z3950_search.pl: Use of uninitialized value $op in string ne at /usr/share/koha/intranet/cgi-bin/acqui/z3950_search.pl line 116. 7) apply patch 8) repeat steps, and those errors will not be generated. Patch(es) to follow.
Created attachment 12723 [details] [review] Bug 8886 - Uninitialized variable triggers error log entry in z3950_search.pl Added "|| q{}" to the end of the declaration/initializations of both $op and $frameworkcode. This prevents n+1 error log entries, where n is the number of frameworks in biblio_framework.
Hmmm... seems that some older patch has been applied... Corrected patch(es) to follow.
Created attachment 13169 [details] [review] z3950_search reducing uninitialized variables error log entries This one is for master.
Created attachment 13170 [details] [review] z3950_search reducing uninitialized variables error log entries (3.8.x/3.6.x) This applies for 3.8.x and 3.6.x versions.
I get the same errors before and after the patch (testing the one for master).
In attempting to generate this issue again in master (3.11.x), some patch in the process of bug 9105 "fixed" the uninitialized variables. Though, "|| q{}" is friendlier to perl critic than "||''". *** This bug has been marked as a duplicate of bug 9105 ***