On Wed, 31 Oct 2001 Ben Rubinstein <[EMAIL PROTECTED]> wrote:
> on 31/10/01 3:54 PM, Ken Ray at [EMAIL PROTECTED] wrote:
> > This has to do with the fact that the Mac uses a carriage return/line-feed
> > combination (CRLF) at the end of each line, and Windows generally uses just
> > LFs (or is just CRs? I can't remember right now). CRs are ASCII 13, LFs are
> > ASCII 10, BTW.
> >
> >on 31/10/01 10:18 AM, Signe Marie Sanne at [EMAIL PROTECTED] wrote:
> >> Could someone please enlighten me as to why ordinary text (no formatting)
> >> uploaded via ftp to a server behaves perfectly when uploading it from
> >> Windows, whereas on Mac all returns have disappeared and been replaced by
> >> lots of boxes? This is with MC2.4.
>
> T'other way, actually. Mac standard to represent a line break is CR; Unix
> standard is LF; DOS/Windows standard is CRLF. Things like this that make me
> despair of ever achieving standards...
The problem just got worse: you never know what you're going to get on
a Mac OS X system...
> This is essentially (correct me if I'm wrong) the difference between 'open
> file for text' and 'open file for binary', or 'URL "file:/...' and 'URL
> "binfile:/...' - in each case, the first formulation instructs MetaCard to
> automatically scan the data, and convert all instances of CR or CRLF to LF.
Right.
> Virtually any FTP application will have the same facility, and have a
> setting that allows you to choose whether to transfer files in Text or
> Binary mode (often also some sort of 'automatic' mode in which it guesses
> whether a file is binary or text). So the real question is, using the FTP
> facilities in MC 2.4, is there a way to specify a similar switch? Or does
> the FTP library always transfer in Binary mode?
Yes, always binary. Which means you have do the translation yourself
using the "replace" command if you want the source or destination
formats to be different.
> Meanwhile, slightly off the original poster's question:
> > CRs are ASCII 13, LFs are ASCII 10, BTW.
> Correct - but bizarrely, MetaCard defines constants named "CR" and "return"
> to have the value 10, instead of 13. A subtle gotcha for HC users who deal
> with binary data, and a wind-up (IMHO).
A historical accident: we didn't start out planning a cross platform
tool, but rather a UNIX-specific authoring tool, which is why we chose
the UNIX line delimiter (no sense in requiring translations everyplace
I/O was done, which would be required if ASCII 13 were used).
"return" was mapped to the native line delimiter as a compatibility
feature. And contrary to your statement, true compability didn't ever
seem to be an issue because HyperCard can't deal with binary data
anyway (nor can any HC user, at least if they're still using HC ;-)
> You have to define your own
> 'constant' if you really want to deal with CR. I can (grudgingly) accept
> the definition of 'return' as linefeed; but defining a new constant "CR",
> with the wrong value, is just rubbing salt in the wound. Was this inherited
> from some other xTalk?
Yup, SuperCard.
> I suppose it's too late to appeal for a change in
> the value of "CR"; but how about at adding a couple of new constants,
> "asciiCR" with value 13, and "CRLF" with the value being a two-character
> string, codes 13 and 10?
CRLF is already built in and generates the correct sequence. And real
programmers don't use "line 1" & return & "line 2", they use
format("line 1\nline 2"). If they need real returns, they can use
format("line 1\rline 2"). numToChar(13) also works.
Regards,
Scott
> Ben Rubinstein | Email: [EMAIL PROTECTED]
> Cognitive Applications Ltd | Phone: +44 (0)1273-821600
> http://www.cogapp.com | Fax : +44 (0)1273-728866
********************************************************
Scott Raney [EMAIL PROTECTED] http://www.metacard.com
MetaCard: You know, there's an easier way to do that...
Archives: http://www.mail-archive.com/[email protected]/
Info: http://www.xworlds.com/metacard/mailinglist.htm
Please send bug reports to <[EMAIL PROTECTED]>, not this list.
