read-line on file handle seeks to EOF

[bairui]

Code Select Expand


(setq file (open {foo} {read}))
(println (seek file))
(read-line file)
(println (seek file))


The first seek prints 0 as expected, however the second one prints the EOF byte position. I couldn't find this behaviour documented in the read-line section of the manual. So... is this a bug in newLISP or me?



If this is normal expected behaviour, how do you suggest I:
[list=1]

[*]search to a place within a file (search file {something})

[*]skip a few lines (read-line file)(read-line file) <-- currently fails here

[*]read a chunk of text (read file buf 1000)

[/list]

Thanks in advance. :-)

[bairui]

I found a workaround for my immediate needs by setting the file pointer to the position after the search:

Code Select Expand


(search file (append {<a name="} search-term {">s*</a>}) true 1)


I'm still not yet skipping the lines after the search, but I imagine I could do that with another regex.



Knowing the more idiomatic way to skin this rat would be awesomer.

[Lutz]

(seek <file-handle> after (read-line <file-handle>) is broken starting version 10.4.0 after speed optimizing 'read-line' on file handles (non std I/O). Other file operations will result in correct seek positions.



This is fixed in the current "in progress" version here:



http://www.newlisp.org/downloads/development/inprogress/">http://www.newlisp.org/downloads/develo ... nprogress/">http://www.newlisp.org/downloads/development/inprogress/



Ps: what OS platform are you on? For Windows or Mac OS X, I can drop a binary executable in that inprogress directory, if this is urgent.

[bairui]

Thanks for the quick reply, acknowledgement of the bug and having it fixed in dev already, Lutz.

This is not an emergency, so I can wait for the update to trickle down. I'm on Arch Linux.



Love newLISP, btw, Lutz - such a clean and pretty little lisp. Thanks for all the good work.