> 
> > 	For some reason I'm having some terminal problems... not on the
> > console, but when I telnet in using ncsa telnet 2.7b4 from another
> > machine, my ^C doesn't kill a process, it suspends it. And, ^U doesn't
> 
> i don't think it suspends the process....just suspends the dump on your
> screen (which is independant of NetBSD). i could be wrong though.

Hmm. I've seen similar behavior, but where "suspend" really means suspend.
When you hit ^C, do you get the "Suspended" message? If not, just ignore all
of what I'm about to say. :-)

On our RS/6K, for some strange reason, all the xterms do what I described.
^C suspends a program, it doesn't kill it. For me, the problem is that
the susp and the dsusp key mappings point to ^C, not ^Z. Check your
setup with an "stty -e". 

> > 	Oh... one thing, is that since I use pico alot I erased the
> > Interrupt Process Key (in ncsa telnet, it gives you an option of your
> > Interrupt, Suspend Output and Resume Output keys. When it's ^C (the
> > default) the ^C function in pico (shows which line you are on) doesn't
> > work, and when I'm programming I pretty much NEED that function, so I know
> > where errors are, etc. 
> 
> yeah, suspend output, that must be it. since those functions are either
> annoying or what-not, just set them to obscure keys, so they'll get out of
> your way.

Sounds good. If you're messing with these options, you could get into
trouble.

> > 	But, would disabling that key, or changing it to something else
> > affect both the ^C and the ^U characters? Do you think it's a
> > NetBSD/terminal emulation problem, or a ncsa telnet problem?
> 
> definately a NCSA telnet problem. i've seen the problem in all
> cases...whether other systems or MUDs.

Hmm. I've never heard about that much trouble with ncsa telnet. But
then again most everyone here uses Stanford's telnet package. Which has
its own bugs. :-)

But an stty -a or -e will answer the terminal emulation vs ncsa telnet
question.

Take care,

Bill