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... 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. 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? 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). 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? 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? Ben Rubinstein | Email: [EMAIL PROTECTED] Cognitive Applications Ltd | Phone: +44 (0)1273-821600 http://www.cogapp.com | Fax : +44 (0)1273-728866 Archives: http://www.mail-archive.com/metacard@lists.runrev.com/ Info: http://www.xworlds.com/metacard/mailinglist.htm Please send bug reports to <[EMAIL PROTECTED]>, not this list.
