ram-ashwin@YALE.ARPA.UUCP (01/28/87)
It looks like some of the files on my 1040ST have lines terminated with
0d-0d-0a (i.e., CR-CR-LF) instead of just CR-LF or LF. I think uEmacs 3.7i
may be the culprit. To test this, I dumped a text file (using DUMP.TOS), in
which end-of-lines showed up as CR-LF. Then I uEmacs'd the file and made a
dummy change to force it to be written out when I exited. Now when I dumped
the same file, end-of-lines showed up as CR-CR-LF. Repeating this didn't add
any more CR's though.
I've been using uEmacs 3.7i for a while now and I never noticed this since OSS
Pascal, 1stLatex, UUdecode, etc. all seemed to work fine with uEmacs'd files.
However, Moshe's latest UUdecode dies when it sees CR-CR-LF. It does decode
freshly UUencoded files, and freshly Kermit'd files (but not Kermit'd and then
uEmacs'd files) so my copy of his program does seem to be correct. Anyone
else run into this?
Could someone please explain what's going on, and what the "correct"
end-of-line terminator is? And whether it really is uEmacs that's doing it
(or is it Kermit (unlikely)? something else?)
Thanx -- Ashwin Ram.
ARPA: Ram-Ashwin@yale
UUCP: {decvax,linus,seismo}!yale!Ram-Ashwin
BITNET: Ram@yalecs
-------turner@imagen.UUCP (01/28/87)
in article <8701272118.AA01023@yale-eli.YALE.ARPA>, ram-ashwin@YALE.ARPA (Ashwin Ram) says: > > It looks like some of the files on my 1040ST have lines terminated with > 0d-0d-0a (i.e., CR-CR-LF) instead of just CR-LF or LF. I think uEmacs 3.7i > > Could someone please explain what's going on, and what the "correct" > end-of-line terminator is? And whether it really is uEmacs that's doing it > (or is it Kermit (unlikely)? something else?) > ok mason, i give up, i'll confess, i did it, i admit it, i did it, and i'm happy that i did....... now that i got that off my chest, the reason i added the extra CR was files from unix only had a LF terminator which was fine unless you wanted to 'show' the file from the desktop, so i changed uEmacs3.7i so that it added a CR at the end of each line, in uEmacs3.8a (the atari version) which is coming real soon now, the problem will be handled correctly, namely it will be a setting from within the editor. i hope that helps. -- --------------- 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
jtr485@umich.UUCP (01/29/87)
In article <8701272118.AA01023@yale-eli.YALE.ARPA>, ram-ashwin@YALE.ARPA.UUCP writes: > I've been using uEmacs 3.7i for a while now and I never noticed this since OSS > Pascal, 1stLatex, UUdecode, etc. all seemed to work fine with uEmacs'd files. > However, Moshe's latest UUdecode dies when it sees CR-CR-LF. It does decode > freshly UUencoded files, and freshly Kermit'd files (but not Kermit'd and then > uEmacs'd files) so my copy of his program does seem to be correct. Anyone > else run into this? > Could someone please explain what's going on, and what the "correct" > end-of-line terminator is? And whether it really is uEmacs that's doing it > (or is it Kermit (unlikely)? something else?) Clearly, uEmacs is broken, not uudecode. CR-CR-LF is 2 end of lines folded together is the standard CPM format (i.e. one CR for each endofline and only one LF). SO uEmacs is putting blank lines between each line of the file which of course terminates uudecode. CORRECT end of line would only have CR or LF. BUT CPM, TOS, MS-DOS etc want CR-LF as end of line. --j.a.tainter > Thanx -- Ashwin Ram. your welcome
braner@batcomputer.UUCP (01/31/87)
[] Standard files on the ST end each line with a CR and then also a LF. So does MS-DOS, as far as I know. UNIX uses just a LF, without a CR. My version of microEMACS has many sections that go like: #if AtST ... #else /* UNIX */ ... #endif and one of the differences is just those line ends. BUT - it will read a file right either way, so if you have a UNIX file on the ST you can fix it by reading it into umacs and then writing it. The report of file length inside umacs is also adjusted to reflect the space it will take on the disk when saved, on that system. Note: that's MY version of umacs, not to be confused with 3.7 and the like, which are separate branches on the tree of evolution of David Conroy's original program. - Moshe Braner