Hello:
  In compiling a current version of C-Kermit, I have run into a small
problem that seems to be related to curses on NetBSD.  Here are some
messages between me and the Kermit developer, Frank da Cruz:

> Date: Thu, 4 Nov 93 13:00:33 EST
> From: Frank da Cruz <fdc@WATSUN.CC.COLUMBIA.EDU>
> To: Jim Spath 410-631-3318 <SPA%NCCIBM1.BITNET@CUVMB.CC.COLUMBIA.EDU> (MD Dept
>  of Environment.2500 Broening Hwy.Balt MD 21224-6612)
> Subject: Re: NetBSD and WREFRESH
> In-Reply-To: Your message of Thu, 04 Nov 93 08:47 EST
> Message-Id: <CMM.0.90.4.752436033.fdc@WATSUN.CC.COLUMBIA.EDU>
>
> > I have compiled the latest code woth CK_WREFRESH defined and now have a
> > refresh key that works.  Thanks.
> >
> You're welcome.
>
> > There is still a problem, however.  I
> > don't know if others have this problem, but during the first file or batch
> > transfer in a session the fullscreen display is fine.  The next attempt,
> > after going back to the remote Kermit and sending more files, shows odd
> > display on the screen.
> >
> I can't make it happen to me, no matter how hard I try.  This is on SunOS, as
> well as AIX and SVR4.  I transferred tons of files, using the latest edit, and
> banged on the refresh key and some of the other interruption keys.  No
> glitches.  However, I have had a few scattered reports like this over the past
> year, and I can only suspect particular curses implementations.  Maybe some
> kind of reinitialization is required on these systems that is not required
> on the systems I've tested.
>
> To get as close to NetBSD as I can from here, I tested Tuesday's code (before
> refresh) on vangogh.berkeley.edu = 4.4BSD -- worked fine, I couldn't break
> it.  Then I ftp'd today's code (with refresh) there, built it, tested it ...
> Same deal, no problems.
>
> So maybe it's a bug or peculiarity of NetBSD curses?  Or your console driver?
> Or your termcap?  Btw, here's one item to check (from ckuins.doc):
>
> C-Kermit maintains a buffer to hold your termcap entry.  The size of this
> buffer is 1024.  Some termcap entries might be longer than this.  To allow for
> longer termcap entries, add a definition of TRMBUFL to your compilation
> CFLAGS, for example:
>
>   -DTRMBUFL=2048
>
> - Frank

> Date: Mon, 8 Nov 93 16:53:52 EST
> From: Frank da Cruz <fdc@WATSUN.CC.COLUMBIA.EDU>
> To: Jim Spath 410-631-3318 <SPA%NCCIBM1.BITNET@CUVMB.CC.COLUMBIA.EDU> (MD Dept
>  of Environment.2500 Broening Hwy.Balt MD 21224-6612)
> Subject: Re: curses foiled again
> In-Reply-To: Your message of Mon, 08 Nov 93 08:57 EST
>
> >   I have looked at the log of the fullscreen file transfer that I sent
> > you, and think I have a clue as to what is going wrong.  The second
> > file transfer has a series of "\b" and "\n" characters (backspace,
> > newline) to get to different places on the screen.  Other areas of
> > the log have "<ESC>[A", which is a cursor movement sequence.  My guess is
> > that the "\n" is expected by curses to drop down one line, but the
> > actual effect is a return to the first position of the next line.
> > I'll look at the curses man pages, and my termcap definitions, to see
> > if I can find a workaround.
> >
> Indeed.  (a) The termcap should not use \n for cursor down unless it knows
> the terminal is in the mood (er, mode) to do this.  And (b) curses should make
> sure the UNIX tty driver isn't itself translating it into CRLF.
>
> - Frank

  I have tried to change the termcap definition to use <ESC>[B, but I am
more familiar with terminfo and may not have gotten it hooked in right.
The problem appears on the console, on VT200 real dumb terminals, and
on MS-Kermit (telnet'd in) doing a VT220 emulation.

  My question is this: is there some TTY flag that needs to be set in order
not to have 'J' turn into 'MJ' inside the terminal, while in curses?

 /jes   <SPA@NCCIBM1.BITNET>  -or-  <spath@jhunix.hcf.jhu.edu>

------------------------------------------------------------------------------