[net.micro.mac] Red Ryder Kermit mode problem explained w/workaround

zben@umd5 (Ben Cranston) (08/26/86)

It appears that the conflict between Red Ryder's "Kermit mode" and various
mainframe Kermit programs is due to Red Ryder's implementation of only the
so-called "image mode" of Kermit, and not the "text mode".

The differance is that "image mode" transfer is strictly byte-for-byte,
while "text mode" attempts to translate the computers' various "newline"
schemes to a machine independant end-of-line representation on the wire.

The conflict comes about because Unix uses LF (Linefeed) as a NewLine
mark while the Macintosh uses CR (Carriage Return), and is complicated 
by the interactions that take place when one Kermit is in text mode
and the other is in image mode.

I have tried to make this known to Scott Watson over GEnie, but as of this
writing (three weeks AFTER I sent him the check for Red Ryder) he has not
seen fit to either reply or authorize me to the Red Ryder roundtable.

Fortunately there is a work-around.  Before downloading a text file from
Unix to the Macintosh, pass the file through the filter:

    tr '\012' '\015'

which translates the LF codes to CR.  Then, use the image mode on the 
Unix version of Kermit:

    % kermit -is <thing>

and the file should end up with the proper EOL codes on the Macintosh.

A similar technique can be done when uploading.  Upload the file with
the image mode set on the Unix Kermit:

    % kermit -ir

then pass it through the filter:

    tr '\015' '\012'

to translate the CR codes to LF to make it a kosher Unix text file.

Be *SURE* to use the image mode on the Unix Kermit:  

If you do not use "image mode" when uploading:

The Unix Kermit will be looking for machine-independant CR-LF pairs for
newlines, and will actually EAT the bare CR codes the Mac is sending,
and you will end up with a Unix file with no newlines at all.  It is 
not possible to recover from this, as the positions of the newlines will 
have been lost forever.

If you do not use "image mode" when downloading:

The Unix Kermit will send CF-LF pairs for newlines, the Mac will interpret
the CR as a newline, and the LF codes will appear as square boxes at the
beginning of each line.  Note that use of the "discard control characters"
option on Red Ryder will probably get rid of these boxes, but will also
get rid of any other control characters in the text.

These shell scripts embody the 'tr' calls documented above, and allow an
optional filename as argument.  They have been tested on Berkeley systems.

% cat ~/bin/crnl

#! /bin/sh
# convert CR to Newlines for Red Ryder Kermit upload
# usage: crnl file  or  command | crnl

eval tr '\\015' '\\012' ${1+'<$1'}

% cat ~/bin/nlcr

#! /bin/sh
# convert Newlines to CR for Red Ryder Kermit download
# usage: nlcr file  or  command | nlcr

eval tr '\\012' '\\015' ${1+'<$1'}

Testing on SVR2, extension to multiple arguments, and other forms of the
dreaded "feeping creaturism" are left as exercises for the student...
-- 
                    umd5.UUCP    <= {seismo!umcp-cs,ihnp4!rlgvax}!cvl!umd5!zben
Ben Cranston zben @ umd2.UMD.EDU    Kingdom of Merryland Sperrows 1100/92
                    umd2.BITNET     "via HASP with RSCS"

srm@iris.berkeley.edu (Richard Mateosian) (08/27/86)

>It appears that the conflict between Red Ryder's "Kermit mode" and various
>mainframe Kermit programs is due to Red Ryder's implementation of only the
>so-called "image mode" of Kermit, and not the "text mode".
>
>The differance is that "image mode" transfer is strictly byte-for-byte,
>while "text mode" attempts to translate the computers' various "newline"
>schemes to a machine independent end-of-line representation on the wire.
>

I have had exactly the same problem using RR 9.2 and Genix 4.1, and I've
been using the same workarounds, except that if you do transfer a file
to the mac without using the filter first, all that happens to you is that
you get a little box (the linefeed) at the start of each line (after the
first).  These can be "changed" to nulls in one "change all" operation,
simply by cutting one of them and pasting it into the "change string" field
of the "change" dialog box.

Richard Mateosian    ...ucbvax!ucbiris!srm 	     2919 Forest Avenue     
415/540-7745         srm%ucbiris@Berkeley.EDU        Berkeley, CA  94705    

jimb@amdcad.UUCP (Jim Budler) (08/27/86)

In article <1197@umd5> zben@umd5 (Ben Cranston) writes:
>It appears that the conflict between Red Ryder's "Kermit mode" and various
>mainframe Kermit programs is due to Red Ryder's implementation of only the
>so-called "image mode" of Kermit, and not the "text mode".
>
>The differance is that "image mode" transfer is strictly byte-for-byte,
>while "text mode" attempts to translate the computers' various "newline"
>schemes to a machine independant end-of-line representation on the wire.
>
>The conflict comes about because Unix uses LF (Linefeed) as a NewLine
>mark while the Macintosh uses CR (Carriage Return), and is complicated 
>by the interactions that take place when one Kermit is in text mode
>and the other is in image mode.
>
>
>Fortunately there is a work-around.  Before downloading a text file from
>Unix to the Macintosh, pass the file through the filter:
>
>    tr '\012' '\015'
>
>which translates the LF codes to CR.  Then, use the image mode on the 
>Unix version of Kermit:
>
>    % kermit -is <thing>
>
>and the file should end up with the proper EOL codes on the Macintosh.
>
>A similar technique can be done when uploading.  Upload the file with
>the image mode set on the Unix Kermit:
>
>    % kermit -ir
>
>then pass it through the filter:
>
>    tr '\015' '\012'
>
>to translate the CR codes to LF to make it a kosher Unix text file.
>
>Be *SURE* to use the image mode on the Unix Kermit:  
>
>If you do not use "image mode" when uploading:
>
>The Unix Kermit will be looking for machine-independant CR-LF pairs for
>newlines, and will actually EAT the bare CR codes the Mac is sending,
>and you will end up with a Unix file with no newlines at all.  It is 
>not possible to recover from this, as the positions of the newlines will 
>have been lost forever.
>
>If you do not use "image mode" when downloading:
>
>The Unix Kermit will send CF-LF pairs for newlines, the Mac will interpret
>the CR as a newline, and the LF codes will appear as square boxes at the
>beginning of each line.  Note that use of the "discard control characters"
>option on Red Ryder will probably get rid of these boxes, but will also
>get rid of any other control characters in the text.
>
>These shell scripts embody the 'tr' calls documented above, and allow an
>optional filename as argument.  They have been tested on Berkeley systems.
>...
>Testing on SVR2, extension to multiple arguments, and other forms of the
>dreaded "feeping creaturism" are left as exercises for the student...

I guess I'm guilty of 'feeping creauturism'.
I do it this way, not for Red Ryder kermit, but for vanilla xmodem
transfer:

With csh:

alias lfcr 'tr "\012" "\015" < \!:1 > \!:2'
alias crlf 'tr "\015" "\012" < \!:1 > \!:2'

Use as follows:

% lfcr inputfile outpufile
% crlf inputfile outpufile

I wont pretend to guess which is better. Mine works, I'm sure his works.
I'm just presenting an alternative. The article was very well written
and informative. Thank You.
-- 
 Jim Budler
 Advanced Micro Devices, Inc.
 (408) 749-5806
 Usenet: {ucbvax,decwrl,ihnp4,allegra,intelca}!amdcad!jimb
 Compuserve:	72415,1200

Once and for all: I like my Macintosh

dec@hpcnoe.UUCP (Danny Cecil) (08/28/86)

Egad!  This is the reason I quit using Red Ryder and started using
VersaTerm.  It correctly handles cr/lf without any user machinations.
I think *Red Ryder* is guilty of "feeping creaturism"!  I certainly have
not regretted switching to VersaTerm.

Danny Cecil
{ihnp4, hplabs}!hpfcla!hpcnof!dec

Standard disclaimers apply.

"Just because you are paranoid doesn't mean someone isn't after you."