Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!sdd.hp.com!decwrl!adobe!heaven!glenn
From: glenn@heaven.woodside.ca.us (Glenn Reid)
Newsgroups: comp.lang.postscript
Subject: Re: eexec?
Message-ID: <205@heaven.woodside.ca.us>
Date: 12 Jul 90 08:15:28 GMT
References: <9101@goofy.Apple.COM> <9102@goofy.Apple.COM>
Reply-To: glenn@heaven.UUCP (Glenn Reid)
Distribution: usa
Organization: Skyline Press, Woodside CA
Lines: 27

In article <9102@goofy.Apple.COM> kevina@apple.com (This space for rent) writes:
|In article <9101@goofy.Apple.COM> I write:
|> Notice that you used "readstring" in the above example instead of 
|> "readhexstring".  Readstring only reads until the first newline, while 
|readhexstring will ignore non-hexadecimal characters (like cr/lf).  The 
|reason that your example works on AppleTalk but not on serial probably has 
|to do with the different handling of newlines. 

|What I really meant to say was readstring treats the newline character(s) 
|as data.  Readline is the operator that reads until an end-of-line 
|indication.  Readhexstring is still the operator of choice.  Now I'm 
|confused, though, as to why it would work under AppleTalk and not serial.  
|How do you send over AppleTalk?  How about an example?

I think you have it right.  As I remember it, the serial driver converts
CR to LF, and it also converts CRLF to LF, which is probably where the
trouble starts.  If you start with two characters and end up with one, you
have a different number of bytes.  Over AppleTalk, CR and LF are just
data as far as the protocol is concerned.

|--Kevin Andresen [kevina@apple.com]
|"Orange whip?  Orange whip?  Three orange whips."

-- 
 Glenn Reid				PostScript/NeXT consultant
 glenn@heaven.woodside.ca.us		Independent Software Developer
 ..{adobe,next}!heaven!glenn		Unparalleled Quality