Description: ------------ The version seems to be a more recent version of pear (ran an update on yum for a FC4 machine - that is the current version) #pear version PEAR Version: 1.4.9 PHP Version: 5.1.2 Zend Engine Version: 2.1.0 ---- Upon using POP3 for retrieving HTML attachments for a PHP script, the script started failing after several weeeks. This code had not been changed at all (PHP code itself), there were no PEAR upgrades, no system upgrades (via yum or any compilations), and I was baffled at why the script started halting when calling an email with an attachment. It would fail ONLY on attachments (which becomes apparent after traceing this error from function to function). Initially, we var_dumped the variables in PEAR that were being called or modified and inserted echo statements to narrow down the point in the PEAR module where the halt was occuring. It seems to be in function _getMultiline() -- it seems that a linebreak was appended to the emails being decoded and thus an error was occuring in the script. at the end of the _recvLN function, the '.' specifies the end of the lines being returned, however if the previous line was an '\n' then the final lineout in $tmp == '\n.'. Thus the if statement following while(!PEAR::isError($tmp = $this->_recvLn())) should read "if($tmp == '.' || $tmp == "\n.") ... Keep in mind some emails still can return on an non-linebreak value. Test script: --------------- /* * Reads a multiline reponse and returns the data * * @return string The reponse. */ function _getMultiline() { $i=0; $data = ''; while(!PEAR::isError($tmp = $this->_recvLn())) { echo $i++ . "|\n|$tmp|\n"; if($tmp == '.'){ echo "return"; return substr($data, 0, -2); } if (substr($tmp, 0, 2) == '..') { $tmp = substr($tmp, 1); } $data .= $tmp . "\r\n"; } return substr($data, 0, -2); } Expected result: ---------------- ----Start [snipped]--- 282| </table> 283| </body> 284| </html> 285| 286| 287|--<<<--==+X[67a4776d638a6d87119f73d2d8165769] --<<<--==+X[67a4776d638a6d87119f73d2d8165769]-- 289|. ---End--- Actual result: -------------- ---Start [snipped]--- 282| </table> 283| </body> 284| </html> 285| 286| 287|--<<<--==+X[67a4776d638a6d87119f73d2d8165769] --<<<--==+X[67a4776d638a6d87119f73d2d8165769]-- 289| . ---End--- the result is a "\n." rather than "."

This bug has been fixed in CVS. If this was a documentation problem, the fix will appear on pear.php.net by the end of next Sunday (CET). If this was a problem with the pear.php.net website, the change should be live shortly. Otherwise, the fix will appear in the package's next release. Thank you for the report and for helping us make PEAR better.