Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!brutus.cs.uiuc.edu!apple!tahoe!wheeler!mikew
From: mikew@wheeler.wrcr.unr.edu (Mike Whitbeck)
Newsgroups: comp.sys.atari.st
Subject: Re: putchar() getchar() problem?
Keywords: extra CR's, MWC
Message-ID: <2831@tahoe.unr.edu>
Date: 27 Jul 89 18:13:18 GMT
References: <2829@tahoe.unr.edu> <33978@grapevine.uucp>
Sender: news@tahoe.unr.edu
Reply-To: mikew@wheeler.UUCP (Mike Whitbeck)
Distribution: usa
Organization: DRI-WRC Reno
Lines: 26


In article <33978@grapevine.uucp> koreth (Steven Grimm) writes:
^In article <2829@tahoe.unr.edu^ mikew@wheeler.UUCP (Mike Whitbeck) writes:
^^HELP ! 
^^I seem to get extra \r's from putchar()!!!! (or getchar()?)
^
^On the ST, the end-of-line code is \r\n, not just \n as it is on UNIX.
^In order to output valid text files, C libraries translate \n to \r\n
^on output, and back the other way on input.
^
^Most C compilers on the ST let you pass a "b" modifier to in the second
^parameter of fopen(); this tells the compiler to skip its I/O translation.
^ ...
^Hope that helps.
^
^sgrimm@sun.com		...!sun!sgrimm

Actually I am not getting the \r\n pair just the \r and somewhat
randomly sprinkled throughout the file.

A la UN*X I planned to use the splay program as a filter using
stdin and stdout. Maybe I can write a scratch file fopen'd as
per your sugesstion and then cat the scratch file to stdout via
Pexec or execvec().

Thanks for the reply.