Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!cbatt!ucbvax!YALE.ARPA!ram-ashwin
From: ram-ashwin@YALE.ARPA.UUCP
Newsgroups: comp.sys.atari.st
Subject: Question about CR/LF and end-of-lines.
Message-ID: <8701272118.AA01023@yale-eli.YALE.ARPA>
Date: Tue, 27-Jan-87 16:18:18 EST
Article-I.D.: yale-eli.8701272118.AA01023
Posted: Tue Jan 27 16:18:18 1987
Date-Received: Wed, 28-Jan-87 21:52:44 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 26

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

-------