[696] in testers
toehold
daemon@ATHENA.MIT.EDU (daemon@ATHENA.MIT.EDU)
Sat May 12 09:27:53 1990
Date: Sat, 12 May 90 09:27:30 -0400
From: David Krikorian <dkk@ATHENA.MIT.EDU>
To: testers@ATHENA.MIT.EDU
Reply-To: dkk@ATHENA.MIT.EDU
On at least some configurations of vaxen, /etc/athena/toehold acts
differently than in 6.4R, in a way that I consider a bug.
The cast:
- One 7.0C (mkserv stand/ops) VAXstation with toehold running on the
VR260 monitor.
What happens:
The VAXstation is "activated" and shows the xlogin greeting window.
I type ^P on the keyboard.
The screen blanks, blinks, flickers and flashes. The cursor goes to
the upper-left corner of the VR260 screen, then prints "xterm died" (I
think) very briefly. Then "Hit any key and pray." (uhhh... make that
"to start.") appears at the top of the screen, as though toehold's
first call to spew() never happened.
After a slight pause, toehold prints "Activating workstation..."
without any keyboard or mouse input having caused it. I have to type
a ^C at toehold here to make it restart (and go to the REAL "Hit any
key..." window), or I just get another xlogin greeting window, which
is a real drag.
What should happen:
When I tell xlogin to die, toehold should cooperate.
Diagnosis and other info:
I've tested this repeatedly on two vaxen of the configuration I
described above. I also went around the Watchmaker Zone activating
the workstations and typing ^P at all the xlogin windows. Only Burn
(a not-quite-standard 7.0 VS2000) showed the bug described above. The
Parallax RT did *not* show the bug, so it may not affect RTs at all.
(I don't want to logout of this one now to check. Too many bug
reports, too little time...)
I suspect the newlines that toehold tries to spew() onto the screen
are somehow being interpreted as keyboard input, rather than screen
output. Obviously, the devious xlogin program will stop at nothing to
stay alive...
