> >
> > > > Ok...now the bug...I was a happy tcsh user until I upgraded today
>(supped
> > > > yesterday afternoon, built all night)...I open up a telnet window on
>my
> > > > xterm, and log in...and do 'ls' and it looks like:
> > > > yuri (thorpej) ~ 12% ls
> > > > total 74
> > > >          2 Mailers/      2 amdstuff/     2 mail/         2 samples/ 

>
> > > > Also...stty intr ^C susp ^Z  no longer works...BTW...This stuff all
>works
>
>I have non-deterministically seen this problem. Never had any problems
>with ^C and ^Z though (bash is my usual shell, but I've tried tcsh also).
>

Me too, although I never use bash.  Tcsh is my primary shell.

> > > > on the console...and it's OK if I rlogin or rsh...So, my guess is 
that
> > > > libtelnet and/or telnetd is hosed.  Anybody?
>
>It's pretty definitely tied up with telnetd and/or your client telnet
>program. (Where do you telnet from?)
>

It happens to me solely on the console.  My telnet and direct connected 
terminals never seem to fail this way.

> > ls isn't at fault; somehow the tty modes are either fouled up or being
> > misinterpreted.  I've noticed that the interrupt character hasn't worked
>> > suspend character does work (and telnet SEND IP also works, so it isn't
 >> signal handling).
>
>I've never had the interrupt character problem, but the problems
>are almost certainly tied up with telnet's LINEMODE options. Try
>compiling telnetd without -DKLUDGELINEMODE (first), then without
>-DLINEMODE.  Also if the client telnet doesn't support LINEMODE at
>all, the problem may not arise, or if the client has proper support
>for LINEMODE, it may work better. (I've seen the same type of
>problems when telnetting to the Cray, where there's even a stty
>-extproc to turn things off). Another related problem is that ~h
>doesn't work right in mail - something that bothered me a lot
>because it seemed to work half the time (when run 'directly' in an
>xterm, as I understand now).
>

I don't know if this is a meaningful data point, but I have pretty much the 
same problems just using tcsh.

It is usually after innd (or most anything else that uses the syslog) tries 
to log a message to root.  Usually, the message will come through loud and 
clear, other times, it will be suppressed.

It seems to happen most frequently when the console is switching from one 
mode to another AND a message from the syslogd tries to get shoved through. 
 It doesn't happen very often, but when it does I usually have a heck of a 
time getting the system back to normal. It will also sometimes (but not 
everytime) happen when a second console message is suppressed.  If the first 
was suppressed and the second is suppressed, suddenly none of the keys work 
without 'return's and other strangeness.  Usually, I end up logging the 
console out and logging back in.  The application I see it most commonly in 
is 'vi'.  Note that this is not a completely new problem.  I have been 
seeing it for several weeks.  I am willing to write it off as a bogosity in 
tcsh, and just live with it until I get more time to look into it.

If it happens while I am in tcsh (waiting at the prompt, for example), none 
of the control characters will work anymore (^Z, ^C, etc.) and programs like 
'more' will cease to function ("invalid ioctl for this terminal" sounds 
familiar). The problem seems (in my case, anyway) to be solely based on a 
problem with a tty mode.   Logging out and in seems to be the only way to 
fix it.  I have tried every combination of recompile, relink, stty resets, 
etc that I can think of.  I even changed the source for tcsh that problem 
with the strange mode when the console is initialized...

TSgt Dave

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