Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!ATC.BOEING.COM!snicoud
From: snicoud@ATC.BOEING.COM (Stephen Nicoud)
Newsgroups: comp.sys.ti.explorer
Subject: RE: Serial IO question
Message-ID: <19900205172637.3.SLN@SKAGIT.atc.boeing.com>
Date: 5 Feb 90 17:26:00 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: inet
Organization: The Internet
Lines: 31


    Date: 3 Feb 90 21:46:00 GMT
    From: mailrus!umich!caen.engin.umich.edu!news@tut.cis.ohio-state.edu  (CAEN Netnews)

    Hi,

    I am working on a project that uses a TI Explorer and a Mac to communicate
    with an external device (a robot) and for that I had to implement my own
    serial IO interface on the Mac (in MACL).  When doing that I found out that
    the TI, when reading a line from the serial port with read-line, consumes
    the character #\Newline and also the character #\Linefeed that follows it.
    The Mac's read-line, on the other hand, doesn't.  The definition of the function
    read-line is to read until a #\Newline is encountered.  
    My question is, what is happening on the TI behind the scenes that causes
    the #\Linefeed to be consumed?  Is the definition of the read-line function
    on the TI different than on the Mac?

    Thanks,

Hmmm.  READ-LINE should behave as you want (i.e., not consuming the #\linefeed).

Take a look at this variable in the SYSTEM package:

;; From SYS:BASIC-FILE;STREAM.LISP#>
(defvar *new-line-delimiter* '(#\newline))   ;Define the delimiters that may seperate lines. Some FTP implements
                                             ; will use the linefeed. This will allow FTP to redefine this variable to
                                             ; suit its application. 

Verify that the :LINE-IN method on the serial stream consults this
variable and that its value is indeed only '(#\newline) and not
'(#\linefeed).