Path: utzoo!mnetor!tmsoft!torsqnt!lethe!yunexus!ists!helios.physics.utoronto.ca!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!uunet!world!lucifer
From: lucifer@world.std.com (Kevin S Green)
Newsgroups: comp.sys.apple2
Subject: Re: BINScii suggestion
Message-ID: <1991Feb7.230029.5458@world.std.com>
Date: 7 Feb 91 23:00:29 GMT
References: <1991Feb3.073400.9131@world.std.com> <1991Feb7.185443.5042@mintaka.lcs.mit.edu>
Organization: The World @ Software Tool & Die
Lines: 28

In article <1991Feb7.185443.5042@mintaka.lcs.mit.edu> dcw@lcs.mit.edu (David C. Whitney) writes:

>> a) making each line of the ProDOS->ASCII conversion start
>>    with a specific deliminator (a la uuencode).
>
>Why? Just curious.
So that implementing b) below would be easier

>> b) the ASCII->ProDOS function have the ability to read through
>>    a file until it encounters the FileStart line without
>>    choking on the Internet (etc) headers. Also be to ignore
>>    any non-BINScii line such as --MORE-- (which would be
>>    easy if suggestion a was implemented).
>Gee, BinSCII *does* skip over everything up to the filestart crud
...edited text
>anything like "--MORE--".  You must be doing something funky.

I already explained in a previous post, but will again:
 - I am using SnowTerm, which can't do file transfers yet.
 - I don't have a lot of disk space on my public unix site so
   saving to disk and then CAT'ing isn't feasible
Therefore, I capture the text of comp.binaries in the buffer
and hand-edit it.


-- 
Kevin S. Green / lucifer@world.std.com / {xylogics;uunet}!world!lucifer
Party naked... /AOL: Gargoth / Pro-line: kgreen@pro-angmar