Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!iuvax!watmath!mks!alex
From: alex@mks.UUCP (Alex White)
Newsgroups: comp.sys.ibm.pc
Subject: Re: Trouble compiling flip with TurboC 1.5
Message-ID: <1333@mks.UUCP>
Date: 25 Jul 89 12:53:21 GMT
References: <26514@agate.BERKELEY.EDU> <1105@unocss.UUCP> <26586@agate.BERKELEY.EDU> <5608@pt.cs.cmu.edu> <1325@mks.UUCP> <55868@tut.cis.ohio-state.edu>
Reply-To: alex@mks.waterloo.edu (Alex White)
Organization: Mortice Kern Systems, Waterloo, Ontario, Canada
Lines: 20

In article <55868@tut.cis.ohio-state.edu> Christopher Schanck <schanck@cis.ohio-state.edu> writes:
>Not to be a pain, but in what situation is this a problem?  If you are
>compiling source generated elsewhere (Unix system, for example), why
>not crank it through a filter to fix things?  Such a filter should be
>trivial to write, yes?  If your editor is generating these files,
>well, then you have more of a problem, but still solvable by switching
>editors.  

You missed something.
We're running over PC-NFS, with all our files on the unix machine.
All our source code resides on unix, we do a lot of our development on unix.
The unix box is effectively our file server, which we can also use independently
We maintain all source in unix format because PC programs (except TC 2.0)
don't care about the CR.
I use vi on the unix box or the pc equally; on the pc I have the vi option
set to not add CR's on writing, so I work with exactly the same files as
on unix.

Of course, there is another reason.  For a say 2,000 line C source file,
thats 2,000 bytes extra of carriage returns for no possible purpose.