sc_dra@bath63.UUCP (02/10/87)
There has been some discussion here recently about the habit of MicroEMACS 3.7i terminating lines with CR CR LF. The patches below fix this problem, at least on my copy of 3.7i which came from a disk of PD software. Hopefully there is only one object version in circulation. offset from to ------ ---- -- 02B61 02 01 02B79 02 01 10DCE 0D 0A Hopefully the port of 3.8 will not have this problem. Anyone got it yet? ----------------------------------------------------------------- ~ Dave Allum, SWURCC, University of Bath, BATH BA2 7AY, U.K. O^O V USENET ..!seismo!mcvax!ukc!bath63!sc_dra / \ JANET dave@uk.ac.swurcc.gecdv /\_/\ _| |_ ISD: +44 225 60371 STD: Bath (0225) 60371
turner@imagen.UUCP (02/12/87)
in article <758@bath63.ux63.bath.ac.uk>, sc_dra@bath63.ux63.bath.ac.uk (Dave Allum) says: > > > There has been some discussion here recently about the habit of > MicroEMACS 3.7i terminating lines with CR CR LF. The patches below > > Hopefully the port of 3.8 will not have this problem. Anyone got it > yet? hopefully 3.8 will come up with a way to solve the following dichotomy; on unix and VMS based systems CR's are considered excess baggage and show up in the editor as \015's; under MSDOS etc. if the lines don't end in CRLF they won't type (read show on the ST) properly. Worse yet some ST utilities blowup if lines terminate in CRLF. The solution that we've come up with is to make it an environment variable, if you can think of a better way please tell me quickly, 3.8e is just about ready. -- --------------- C'est la vie, C'est le guerre, C'est la pomme de terre Mail: Imagen Corp. 2650 San Tomas Expressway Santa Clara, CA 95052-8101 UUCP: ...{decvax,ucbvax}!decwrl!imagen!turner AT&T: (408) 986-9400
john@viper.UUCP (02/16/87)
In article <863@imagen.UUCP> turner@imagen.UUCP (D'arc Angel) writes: >Worse yet some ST utilities blowup if lines terminate in CRLF. That is bad... Then again, I've yet to find any programs which do this. Since the de-facto standard for ST text files is to terminate them with CRLF, that's the way to go. Any program which is written in such a way so as to blow up if it receives a CRLF terminated line will blow up on most ST text files and can safely be considered buggy... Writing a routine which will read text terminated with CR, LF, or CRLF is non-trivial, but not too difficult. If you're really having problems with this, please contact me directly. Include the current code for the input loop, and I'll send back a portable version that can handle all 3 forms....
paone@topaz.UUCP (02/16/87)
There is a CR/LF problem with (where else?) Lattice C. The source can end this way without any problems, but the control file for the linker cannot. If it does, it gives error mssages that are next to impossible to guess have anything to do with the .lnk file. I was going crazy for a few hours when this happened before I realized it. -- Phil Paone paone@topaz.rutgers.edu "Admiral...There be whales here"