Text files driving me mad
raney at metacard.com
Thu Jun 13 12:28:00 CDT 2002
On Thu, 13 Jun 2002 Dar Scott <dsc at swcp.com> wrote:
> On Thursday, June 13, 2002, at 09:06 AM, Troy Rollins wrote:
> > On Thursday, June 13, 2002, at 10:56 AM, Ben Rubinstein wrote:
> >>>> I found it slightly confusing that CR (return) and linefeed are
> >>>> both ASCII 10,
> >>> I find it irritating.
This behavior is just a historical accident: we had to be compatible
with HyperCard, which used "return" for a line delimiter (which is
standard on the Mac) and with our original platform, UNIX, which uses
lineFeed as a line delimiter. In hindsight I would still say that it
was the right choice because the number of people doing HC/SC/OMO
conversions and using UNIX vastly outnumber the people doing binary
reads from serial devices (which is pretty much the only place this is
We're starting to see a lot of related conflicts on OS X because half
the tools for that platform one delimiter and the other half use the
> I think the uniform internal handling of lines is a good thing. I
> think that converting back and forth between internal and host is
> good. But! But we have to assume that something can go wrong.
> Because of this a binary option should always be available. Some
> folks might want to always go binary and handle the conversion
> themselves. I think binary is available on all file I/O and is
> required for TCP/IP, but it is missing in open process. It might
> be missing in other places, too.
"open process <p> for binary read" works fine here...
> For serial, I read until empty, which means in that context, "give
> me all in your buffer". I read binary, so I accumulate and process
> that. Depending on the protocol, I use a regEX to pull off the
> message (such as a line) from (near) the front and stuff the rest
> back into my buffer. It handles extra chars, too. The message is
> sent on.
Sounds like the right way to me too. Doing a "replace" on incoming
and outgoing data will also take care of the problem, just be sure to
use "numToChar" to specify the character.
> What could be a good name for ASCII 13 in Revolution? Besides
> numToChar(13), I mean.
A new constant for this might be nice to have, but we're coming up on
10 years (next month!) with the existing behavior with no one having
suggested that this is necessary until today. The suggestion of
declaring a constant at the top of your scripts seemed like a good one
to me too.
> Dar Scott
Scott Raney raney at metacard.com http://www.metacard.com
MetaCard: You know, there's an easier way to do that...
More information about the use-livecode