On Fri, 10 Jun 2005 23:34:31 +0200 Andreas Gohr <andi@xxxxxxxxxxxxxx> wrote: > Hmm maybe I understood the documentation wrong... > Here is what I thought: fgets should return either a complete > line (with one newline at the end or 8192 bytes of other chars... in > both cases we can expect more output from aspell so we continue > to read. I aggree so far > If aspell outputs an empty line, fgets should return exactly one byte > with a newline... correct? You would get a single newline if aspell sent one. In our case aspell sent the beginning of the next line, but the remaining output buffer is too short to host it completely. So aspell was interrupted writing to the buffer. Fgets reads until it gets a newline or the given size is reached. The incomplete line does neither contain a newline nor is it 8192 bytes long. The result is that fgets waits forever. > So obviously this didn't work for you (while it did for me) can you > point me in the right direction and tell me how you fixed the loop? It's a quicke and dirty hack. I replaced the do/while loop with following lines: stream_set_blocking($pipes[1], FALSE); while($r = fgets($pipes[1],8192)) $out .= $r; > Well these changes did correct the output for me so i can't be all wrong ;-) Your point :-) > You're right! That's very strange - straight from the manual: It seemed that the aspell manual is incomplete. There are two possible solutions: Ignore lines beginning with '?' or parsing them. I would plead for the last one. :-) Do you have any idea why some spellchecker links are so heavily damaged? I think this a major point because those corrupted links mostly use more than one line of text and therefore shift the whole text. This might be the cause for the offset I see. I think if we found the cause for the corrupted links the text would no longer be corrupted. Best regards Matthias -- DokuWiki mailing list - more info at http://wiki.splitbrain.org/wiki:mailinglist