francis@csli.Stanford.EDU (Dave Francis) (07/30/90)
I am trying to append a carriage return to a line of text that I am outputting to a simple ascii file using FSWrite on C strings. To accomplish this I figured len = 1L; err = FSWrite(refNum, &len, "\n"); would work. But instead I get unrecognizable characters (those rectangles) instead of carriage returns when I look at the file with TeachText. How do I get a real carriage return appended? Thanks, Dave Francis P.S. I am using Think C 4.0.2
minow@mountn.dec.com (Martin Minow) (07/31/90)
In article <14711@csli.Stanford.EDU> francis@csli.stanford.edu (Dave Francis) asks about writing a carriage return to a line of text using FSWrite: > >len = 1L; >err = FSWrite(refNum, &len, "\n"); > Unfortunately, this didn't work. C programs on the Macintosh live in two "universes" -- the Mac universe and the (Ansi) C universe. If you write for the C universe, your program printf's '\n' and the C run-time library does whatever is needed to create a new line. This varies -- wildly -- on the systems that support C. On the Macintosh, a newline is signalled by a <carriage return> character, Hex 0D (Octal 015). Thus, the "proper" way to write a Mac-style carriage return using FSWrite is err = FSWrite(refNum, &len, "\015"); but most of us write FSWrite(... "\r") which isn't quite correct if you're into nit-picking, but works anyway. In any case, you should still use "\n" if you're writing a file created by fopen(). Martin Minow minow@bolt.enet.dec.com
nick@lfcs.ed.ac.uk (Nick Rothwell) (07/31/90)
In article <14711@csli.Stanford.EDU>, francis@csli (Dave Francis) writes: >len = 1L; >err = FSWrite(refNum, &len, "\n"); > >But instead I get unrecognizable characters (those rectangles) >instead of carriage returns when I look at the file with TeachText. >How do I get a real carriage return appended? Using "\r" should do it. My understanding (I'm open to correction) is that the ANSI I/O library stuff in THINK C does \r -> \n conversion on the way in, and \n -> \r conversion on the way out, so standard C programs can deal with Mac TEXT files while having lines appear to be \n-delimited. FSWrite is a toolbox call, and so it's in Mac-land, with explicit \r's everywhere. This whole business really is a pain, especially if you want to start doing things with binary files passed between different hosts. Nick. -- Nick Rothwell, Laboratory for Foundations of Computer Science, Edinburgh. nick@lfcs.ed.ac.uk <Atlantic Ocean>!mcsun!ukc!lfcs!nick ~ ~~ ~~ ~~ ~~ Hey, son, get that DeLorean off the track! And ~~ ~~ ~~ ~~ ~ what have you done with all my lovely harpsichords?
minow@mountn.dec.com (Martin Minow) (08/01/90)
In article <5434@castle.ed.ac.uk> nick@lfcs.ed.ac.uk (Nick Rothwell) notes that THINK C converts '\r' to '\n' when it reads files (and converts in the other direction when it writes files): > >This whole business really is a pain, especially if you want to start >doing things with binary files passed between different hosts. > If you open the file as fopen("file", "rb" [or "wb"]), THINK C supresses conversion. The 'b' (binary) mode is part of the ANSI C standard. It should be mentioned in the THINK C library documentation. Martin Minow minow@bolt.enet.dec.com