Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!usc!apple!apple.com!kevina
From: kevina@apple.com (This space for rent)
Newsgroups: comp.lang.postscript
Subject: Re: eexec?
Message-ID: <9101@goofy.Apple.COM>
Date: 12 Jul 90 01:08:11 GMT
Sender: usenet@Apple.COM
Distribution: usa
Organization: Apple Computer, Inc.
Lines: 24
References:<1223@mtk.UUCP> <1388@chinacat.Unicom.COM>

In article <1388@chinacat.Unicom.COM> woody@chinacat.Unicom.COM (Woody 
Baker @ Eagle Signal) writes:
> I have discovered that Appletalk and the serial port handle things
> diffrently when you send stuff like that.  for example, the following
> apparently works on  appletalk, but flat fails over the serial port.
> 
> currentfile 200 string readstring
> 22aa1f2f.....(200 bytes worth of hex data)
> 
> Under the serial port, if you send a cr/lf in the middle of the hex
> string, it will give you an error message.  The only way that I have
> found to make it work, is to bracket the hex data with
> <.....hex....>   That works.  I have recieved several cexec files that
> flat would not work until the <> was wrapped around the hex.  The RED
> book specifies that the <> are required, but apparently does not
> enforce it over appletalk.
> 
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. 

It is a fluke of eexec that the same data produces the same results whether bracketed by <> or not (see section 7.2 of the Black Book for an explanation of why) -- in all other situations the angle brackets are required to specify hex data.

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