PEAR Bug Search Results

Structures_BibTex: Bug 16477 [Open] Infinite loop in the parser when a comma is missing

arnoques at yahoo dot com dot ar — 2009-07-28T00:50:47+00:00

Structures_BibTex Bug
Reported by arnoques
2009-07-28T00:50:47+00:00
PHP: 5.1.2 OS: Linux Package Version: CVS

Description:
------------
The parser also gets into an infinite loop when processing an entry like this:

@ARTICLE{key,
  author = {LastName, Name}
  title = {a title},
  journal = {a journal}
}

It gets confused because the parser searches for titles between a ',' and a '=', so it believes that "Name}\n\ttitle" is the name of the field. The infinite loop is triggered in the while loop at lines 383-393, when the parser assumes that, since the braces are not balanced in "= {LastName," there must be a previous "=".

If there's no comma inside the author field, the program still gets confused but it doesn't trigger the infinite loop.

I agree with the submitter of a previous bug that the parser needs a serious rewrite. It should accept and reject the same inputs that the original bibtex program does.

Test script:
---------------
Run the script on the previous entry

require_once 'BibTex.php';
$bibtex = new Structures_BibTex();
$ret    = $bibtex->loadFile('test.bib');
$bibtex->parse();
print_r($bibtex->warnings);

Expected result:
----------------
An error stating that there is a missing comma (and several warning due to missing fields, but I know that's not yet implemented).

The output of bibtex is
~$ bibtex test
This is BibTeX, Version 0.99c (Web2C 7.5.4)
The top-level auxiliary file: test.aux
The style file: plain.bst
Database file #1: test.bib
I was expecting a `,' or a `}'---line 3 of file test.bib
 :
 :   title = {a title},
(Error may have been on previous line)
I'm skipping whatever remains of this entry
Warning--empty title in key
Warning--empty journal in key
Warning--empty year in key
(There was 1 error message)


Actual result:
--------------
Infinite loop at lines 383-393

Structures_BibTex: Feature/Change Request 16010 [Open] TeX special characters should be escaped in BibTeX exports

craigloftus+pear at googlemail dot com — 2009-03-10T17:25:38+00:00

Structures_BibTex Feature/Change Request
Reported by craigloftus
2009-03-10T17:25:38+00:00
PHP: Irrelevant OS: All Package Version: CVS

Description:
------------
The bibTex method should be escape TeX special characters such as & and %. These should be output as \& and \% respectively. Not doing so could be seen as a bug... but I thought I would put this in as a feature request.

I provide a patch to add this feature. Bascially I've just pinched some code from another PEAR package (Text_Wiki) and put calls into the appropriate places.

I don't know what your patch guidelines are (and I haven't spent much energy looking). I have tried to match coding/comment  style and the patches in CVS. I will be happy to revise if there are any problems.

Structures_BibTex: Bug 15924 [Assigned] Warning: split() [function.split]: Invalid preceding regular expression

shamantobi at gmail dot com — 2009-03-01T22:38:54+00:00

Structures_BibTex Bug
Reported by lgalarra
2009-02-20T21:11:48+00:00
PHP: 5.2.5 OS: Linux Package Version: 

Description:
------------
      Dear developers:

My project (http://joomla-research.com) is using this library to parse sets of Bibtex entries, however a user reported a really strange bug in which  the parse method could not retrieve the type of entry ('entryType' property in the result array). By debugging the code I found the following problem in line 423 :

split() [function.split]: Invalid preceding regular expression in ... line 423

which produces variable $arr to be empty. 

I check PHP documentation for function split and found that this takes a pattern as first parameter which made me realize, regexp special characters should be escaped. The mentioned line says:

            $arr = split('{', $entry);

I changed it to:

            $arr = split('\{', $entry);

and the bug was gone. I have to add that my user is using PHP 5.2.6 (Why does it not appear in the list?) It is the first time something similar happen. Furthermore, this change did not affect other installations.

Test script:
---------------
         

Expected result:
----------------
         

Actual result:
--------------

Structures_BibTex: Bug 15323 [Open] Multiple entries with the same cite

sausis at vtex dot lt — 2008-12-27T00:22:50+00:00

Structures_BibTex Bug
Reported by sausis
2008-12-16T09:36:39+00:00
PHP: 5.2.1 OS: WinXP Package Version: 1.0.0RC4

Description:
------------
Notice: Undefined offset:  ## in C:\php\PEAR\Structures\BibTex.php on line 320

Indexes of non unique cites in $cite array are not in $unique after array_unique (line 315) therefore test ('' == $unique[$i]) in loop (line 320) generates notice.

Structures_BibTex: Bug 14442 [Open] Undefined variable $entry in _removeCurlyBraces

steve at weblite dot ca — 2008-08-03T09:39:25+00:00

Structures_BibTex Bug
Reported by shannah
2008-08-03T09:39:25+00:00
PHP: 5.2.6 OS: All Package Version: CVS

Description:
------------
The _removeCurlyBraces method starts like:

    function _removeCurlyBraces($value)
    {
        //First we save the delimiters
        $beginningdels = array_keys($this->_delimiters);
        $firstchar     = substr($entry, 0, 1);
        $lastchar      = substr($entry, -1, 1);
        ....


At this point there is no defined variable $entry in the context - hence 
I'm thinking this must be a typo of sorts.  Is
substr($entry, 0, 1);
substr($entry, -1,1);
meant to be
substr($value, 0, 1);
substr($value, 0, 1);
?

Structures_BibTex: Bug 14438 [Open] Regular expression for removeCurlyBraces wrong

wbaxter at gmail dot com — 2008-08-03T01:11:55+00:00

Structures_BibTex Bug
Reported by baxissimo
2008-08-03T01:11:55+00:00
PHP: 5.2.6 OS: Linux Package Version: 1.0.0RC4

Description:
------------
The removeCurlyBraces option doesn't work on curly braces that appear around the first word in an entry.

That's because the regular expression used is:

 $pattern     = '/([^\\\\])\{(.*?[^\\\\])\}/';

The text before the '{' is not optional, so it won't match if there's nothing before.  If you make "beginning of string" a possibility then it seems to work properly:

  $pattern     = '/([^\\\\]|^)?\{(.*?[^\\\\])\}/';

Version info in what I'm using is:

   * @category   Structures
   * @package    Structures_BibTex
   * @author     Elmar Pitschke 
   * @copyright  1997-2005 The PHP Group
   * @license    http://www.php.net/license/3_0.txt  PHP License 3.0
   * @version    CVS: $Id: BibTex.php,v 1.16 2007/03/26 21:13:59 hugoki Exp $
   * @link       http://pear.php.net/package/Structures_BibTex


Test script:
---------------
Run it on a bibtex file like this

@ARTICLE{FOO,
  title = {{FoOBaR}: A system with {StrAnGe} capitalization},
}


require_once 'Structures/BibTex.php';
$bibtex = new Structures_BibTex();
$bibtex->setOption('removeCurlyBraces', true);
$ret    = $bibtex->loadFile('foo.bib');
if (PEAR::isError($ret)) {
    die($ret->getMessage());
}
$bibtex->parse();

echo $bibtex->data[0]['title'];

Expected result:
----------------
FoOBaR: A system with StrAnGe capitalization

Actual result:
--------------
{FoOBaR}: A system with StrAnGe capitalization

Structures_BibTex: Bug 13100 [Open] parser gets hung

alexis at ling dot upenn dot edu — 2008-02-11T09:11:02+00:00

Structures_BibTex Bug
Reported by alexis
2008-02-11T09:11:02+00:00
PHP: 5.2.0 OS: Linux Package Version: 1.0.0RC4

Description:
------------
The file-parsing code does not handle strings properly, and gets confused when @ signs appear in strings (as in \latex@macro). The test below is distilled from my preamble.

Frankly, parse() and parseEntry() are a terrible mess and should be refactored into a state machine that distinguishes top-level, in-entry and in-string states. The first embedded @ in the test triggers a warning TWICE, then the second gets stuck in the loop...

Test script:
---------------
cat > example.php
  @PREAMBLE{ "{@url} @..." }
^D


Expected result:
----------------
The code should terminate

Actual result:
--------------
infinite loop