Subject: Re: Carriage return in PICO

From: [email-masked] (Adam H. Kerman)
Date: 6 Oct 1996 22:29:22 -0500

In article <[email-masked]>,
Robert Gonzalez <[email-masked]> wrote:
>Pico doesn't seem to use character 13 for end of line.

>When I download a textfile, everything is all run together.

>Does anyone know how to deal with this problem other than manually 
>editing the file after I download it?

[I assume you are downloading from a Unix to a DOS system.]

Text files in Unix and DOS use different end-of-line conventions. Unix
uses a "New Line" character (same as LF in DOS). DOS (and CP/M) uses 2
characters, a Carriage Return and Line Feed at the end of each line. The
Mac uses only a CR.

If you use Z-MODEM to download and invoke it from the Unix command line,
use the -a switch to automatically change to DOS end-of-line conventions.
Thusly:

sz -a my.text.file

---

From: Paul O Bartlett <[email-masked]>
Date: Sun, 6 Oct 1996 16:52:50 -0400

> editing the file after I download it?

    This could possibly be a result of incompatible settings in the two
different communications programs you are using for the download -- one
program running on your "host" (where your textfile is) and one on your
"desktop" (where you are trying to download to).  A lot of the *good*
dekstop communications programs have the ability to adjust the lineends
on the fly during transmission and reception.  Check your user's
manual.

Paul                             <[email-masked]>
----------------------------------------------------------
Paul O. Bartlett, P.O. Box 857, Vienna, VA 22183-0857, USA
Finger, keyserver, or WWW for PGP 2.6.2 public key 
Home Page:  URL: http://www.access.digex.net/~pobart

---

From: [email-masked] (Robert Gonzalez)
Date: 6 Oct 1996 20:14:10 GMT

Robert J. Gonzalez
[email-masked]

---

From: [email-masked] (Adam H. Kerman)
Date: 9 Oct 1996 16:57:27 -0500

In article <[email-masked]>,
Tim Mooney <[email-masked]> wrote:
>In article <[email-masked]>,
>Steven King <[email-masked]> wrote:
>> Adam H. Kerman <[email-masked]> wrote:

>> Again, it's no
>> big deal to convert, but then again it would be no big deal to write Pine
>> to handle it itself...

>And it shouldn't be any big deal to just transfer it in ASCII mode rather
>than in binary mode.  If you ever use `ftp', this is an important thing to
>remember so it's something you may need to be thinking about anyway.

[Nothing that I had written earlier remains in your citation!]

This isn't an ASCII vs. binary transfer issue. He is making an ASCII
transfer. The trouble is the ASCII character used for the line boundary on
Unix systems (New Line, 010) is meaningless on the Mac, his home computer. 
Macs require a Carriage Return, 013.

A simple search and replace operation will solve his problem at home.

---

From: "Steven King" <[email-masked]>
Date: 7 Oct 1996 17:18:10 GMT

>characters, a Carriage Return and Line Feed at the end of each line. The

On a related note, would it be too much for the Development Gods to allow
Pine to accept either end-of-line convention in its own files?  I just got
my wife up and running on PC-Pine, and we copied her addressbook from the
Unix box where she had been working.  PC-Pine couldn't make any sense of
it.  All I had to do was convert the end-of-line from Unix's LF to
DOS's CRLF pair, so it wasn't a big deal.  Still, this is something that
could be handled internally to Pine without too much trouble.

Out of curiosity, does PC-Pine handle Unix newlines in mail folders?  I
haven't tried copying over all her old mail folders yet.  Again, it's no
big deal to convert, but then again it would be no big deal to write Pine
to handle it itself...

-- 
----------------------------------------<Steven King, [email-masked]>--
"This paperclip will serve as an antenna, grabbing neutrinos from the cosmos
    and providing ignition for this craft."
"Astonishing, Brain!  Um, will it also roast marshmallows?"

---

From: Mike Brudenell <[email-masked]>
Date: Thu, 10 Oct 1996 09:37:57 +0100 (BST)

Ummm.... I think I disagree with your assertion that "This isn't an ASCII
vs. binary transfer issue"...

A "binary" transfer copies over a file's content byte for byte, which is
necessary for binary data files such as images but useless for text files
unless both source and destination computer systems share the same
end-of-line conventions.

In contrast an "ascii" transfer converts the line ending used by the
source computer into a standard form (what character(s) get used for this
I admit I forget/never knew).  The receiving computer spots each of these
standard endings and converts them into its own (possibly different) line
ending.

This makes it possible to exchange files using ascii ftp transfers between
such diverse systems as:

*  UNIX (line feed only at line end)
*  Macintosh (carriage return only at line end)
*  PC (carriage return + linefeed at line end)
*  VMS (a 2-byte line length count followed by data, possibly including
   both carriage return and/or line feed characters!)

Cheers,

-- 
Mike Brudenell                                         <[email-masked]>
------------------------------------------------------------------------
The Computing Service, University of York, Heslington, York, YO1 5DD, UK
Tel: +44-1904-433811  FAX: +44-1904-433740  http://www.york.ac.uk/~pmb1/

---

From: [email-masked] (Robert Gonzalez)
Date: 9 Oct 1996 22:49:38 GMT

Adam H. Kerman ([email-masked]) wrote:
: In article <[email-masked]>,
: Robert Gonzalez <[email-masked]> wrote:
: >Adam H. Kerman ([email-masked]) wrote:
: >: In article <[email-masked]>,
: >: Robert Gonzalez <[email-masked]> wrote:
: 
: >: If you use Z-MODEM to download and invoke it from the Unix command line,
: >: use the -a switch to automatically change to DOS end-of-line conventions.
: >: Thusly:
: 
: >: sz -a my.text.file
: 
: >This sounds like it would solve my problem, only I'm not using a dos 
: >computer, and I don't have zmodem available, just xmodem and ymodem.
: 
: >Everything else works prefectly, it's only when I download a textfile 
: >that I have the problem.
: 
: >I've been going in and adding <> where there should be using a CR and 
: >using search and replace in my wordprocessing program.
: 
: >This is tedious
: 
: So you're on a Mac? As I said earlier, the end-of-line convention is CR. 
: Since you can do search and replace already, simply substitute CR for NL.
: (ascii 013 for ascii 010)
: 

ASS/U/MEing?

I'm using a Commodore 128 with Desterm 2.0.  It uses 13/10 pairs (the 10 
usually added automatically)

Maybe I'll just leave well enough alone.

---

From: [email-masked] (Adam H. Kerman)
Date: 8 Oct 1996 15:17:42 -0500

In article <[email-masked]>,
Robert Gonzalez <[email-masked]> wrote:
>: In article <[email-masked]>,
>: >Pico doesn't seem to use character 13 for end of line.

>: >When I download a textfile, everything is all run together.

>: >Does anyone know how to deal with this problem other than manually 
>: >editing the file after I download it?

>: [I assume you are downloading from a Unix to a DOS system.]

>: Text files in Unix and DOS use different end-of-line conventions. Unix
>: uses a "New Line" character (same as LF in DOS). DOS (and CP/M) uses 2
>: characters, a Carriage Return and Line Feed at the end of each line. The
>: Mac uses only a CR.

>: If you use Z-MODEM to download and invoke it from the Unix command line,
>: use the -a switch to automatically change to DOS end-of-line conventions.
>: Thusly:

>: sz -a my.text.file

>This sounds like it would solve my problem, only I'm not using a dos 
>computer, and I don't have zmodem available, just xmodem and ymodem.

>Everything else works prefectly, it's only when I download a textfile 
>that I have the problem.

>I've been going in and adding <> where there should be using a CR and 
>using search and replace in my wordprocessing program.

>This is tedious

So you're on a Mac? As I said earlier, the end-of-line convention is CR. 
Since you can do search and replace already, simply substitute CR for NL.
(ascii 013 for ascii 010)