[comp.sys.apple] Binscii mess

SEWALL@UCONNVM.BITNET (Murph Sewall) (04/07/89)

>  Proterm's Kermit sure messed up my Hyper C download -- in BinSCII format,
>but Executioner format is fine. I've been downloading Executioner format
>files with Proterm for a long time now.

Other messages indicate that which version of ProTerm your using makes a
BIG difference.  It would be helpful if comments referring to ProTerm's
problems (or lack of them) specified which version is in use.

Murph Sewall                       Vaporware? ---> [Gary Larson returns 1/1/90]
Prof. of Marketing     Sewall@UConnVM.BITNET
Business School        sewall%uconnvm.bitnet@mitvma.mit.edu          [INTERNET]
U of Connecticut       {psuvax1 or mcvax }!UCONNVM.BITNET!SEWALL     [UUCP]

-+- I don't speak for my employer, though I frequently wish that I could
            (subject to change without notice; void where prohibited)

According to the American Facsimile Association, more than half the calls
from Japan to the U.S. are fax calls.  FAX it to me at: 1-203-486-5246

CYLau@UNCAMULT.BITNET (The Ultron) (04/07/89)

Reason why ProTerm's Kermit messes up the majority of BinSCII format
downloads:  ProTerm's Kermit protocol automatically translates lf into
crlf (or something similar to that), but what that does, is if the file
was BinSCII'd for a Unix system (with only lf separating) ProTerm will
translate all those into crlf..  and BinSCII will choke on the extra cr
on each line...  Executioner on the other hand, doesn't care what's on
the end of a line, as long as the line is terminated (it DOES, but it
doesn't choke like BinSCII when something extra is added) To correct
this problem, there are several solutions:

 1- Download with an xmodem variant-> xmodem preserves the current form
 of the file and thus BinSCII will have no problems
 2- After download, load the file into the ProTerm editor (one of the ONLY
 things I LIKE about ProTerm) and replace all cr with nothing (ie. do
 a replace of ctrl-m with nothing (hit return in response to
 "replace with" prompt)) and then resave the file and process with BinSCII
 3- Get the "REAL" Kermit 65 (thanks to Ted Medin for this wonderful program!)
 and turn off the crlf translation before downloading...  (Kermit 65 3.85
 is also a bit faster than ProTerm's Kermit, especially if you set the
 packet size to maximum (ProTerm is limited to the "standard" 80
 character packet))

Those are the solutions to the problems...  none are really elegant...
Maybe someone can fix BinSCII so it doesn't choke on a unix encoded
BinSCII which has extra cr's inserted??  (Dave Whitney-> Are you
listening??)

Chris




-------------------------------------------------------------------------
 The opinions expressed herein are    Replies to:
 entirely my  own, but they can be      CYLau@UNCAMULT.BITNET
 yours for only  $29.95 plus tax.*      CYLau%UNCAMULT@MITVMA.MIT.EDU
 (* where applicable.)                  (or whatever is on the header)
-------------------------------------------------------------------------

ERAN@BGUVM.BITNET (Eran Lachs) (04/07/89)

  Proterm's Kermit sure messed up my Hyper C download -- in BinSCII format,
but Executioner format is fine. I've been downloading Executioner format
files with Proterm for a long time now.

Eran Lachs
Bit >> eran@bguvm

nakada@husc4.HARVARD.EDU (Paul Nakada) (04/07/89)

From article <8904062148.aa13319@SMOKE.BRL.MIL>, by SEWALL@UCONNVM.BITNET (Murph Sewall):
>>  Proterm's Kermit sure messed up my Hyper C download -- in BinSCII format,
>>but Executioner format is fine. I've been downloading Executioner format
>>files with Proterm for a long time now.
> 
> Other messages indicate that which version of ProTerm your using makes a
> BIG difference.  It would be helpful if comments referring to ProTerm's
> problems (or lack of them) specified which version is in use.
> 
> Murph Sewall                       Vaporware? ---> [Gary Larson returns 1/1/90]

the key feature of binscii is that kermit is not necessary as far as
transfer protocols are concerned.  A straight binary transfer will
suffice since binscii can deal with different types of line terminators,
(which kermit normally fiddles with).. for users of proterm, i recommend
using any of the binary transfer protocols (xmodem, ymodem) which are
almost always available on your host machines (if not talk to your
system administrator, because they should be)

-paul nakada

 __
|     Paul Nakada  '89   #8-)  |                                          
      North House              |                nakada@husc4.HARVARD.EDU  
      Harvard College          |       seismo>!harvard!husc4!nakada.UUCP  
      Cambridge, MA  02138     |     rutgers/   nakada@husc4.BITNET       
      617/498-6255 || 6264     |                                         __|

dcw@SUN-BEAR.LCS.MIT.EDU (Dave Whitney) (04/09/89)

BinSCII uses the upper and lower case letters, the ten digits, and open
and close parens in its files. Nothing else. I picked those characters so
that they'd be unobtrusive to mailers going to IBM (EBCDIC) machines.

Is the problem people are having related to uploading to the host or
downloading from the host? If they're having trouble uploading, then
it could be that they are using the wrong line terminator option (in
BinSCII). When using Kermit, they should have BinSCII create files
with CR as the line terminator.

Right now, BinSCII 1.0.2 ignores whitespace when decoding files. I
can't figure out why people are having troubles with 'shifted' lines
if they are using v1.0.2.

	Dave

SEWALL@UCONNVM.BITNET (Murph Sewall) (04/09/89)

>the key feature of binscii is that kermit is not necessary as far as
>transfer protocols are concerned.  A straight binary transfer will
>suffice since binscii can deal with different types of line terminators,
>(which kermit normally fiddles with).. for users of proterm, i recommend

Kermit can do straight binary transfers (just remember to set file-type
binary on both ends).

>using any of the binary transfer protocols (xmodem, ymodem) which are
>almost always available on your host machines (if not talk to your
>system administrator, because they should be)

I'd guess you've never used an IBM host :-)

Aside from the fact that IBM hosts only speak in 7 bit (mark or even parity),
they are EBCDIC - so there's no such thing as a "simple" xmodem type transfer
(that's why Kermit was invented in the first place!).

Also, IBM has a variety of "solutions" for letting MS-DOS PC's (and even
Macintoshes) speak to their hosts.  My experience with IBM system
administrators is that they DISTAIN the idea of anything as humble as an
Apple 2 connecting to their host (mine is astonished at the notion that there
are users out there with Kermit running on their Atari-ST's and Commodore
64's :-).  The usual response to an xmodem question is to get Kermit
(or an IBM-PC running YTerm or a Macintosh running TinCan).

Murph Sewall                       Vaporware? ---> [Gary Larson returns 1/1/90]
Prof. of Marketing     Sewall@UConnVM.BITNET
Business School        sewall%uconnvm.bitnet@mitvma.mit.edu          [INTERNET]
U of Connecticut       {psuvax1 or mcvax }!UCONNVM.BITNET!SEWALL     [UUCP]

-+- I don't speak for my employer, though I frequently wish that I could
            (subject to change without notice; void where prohibited)

According to the American Facsimile Association, more than half the calls
from Japan to the U.S. are fax calls.  FAX it to me at: 1-203-486-5246