francis picabia wrote:
> Bob Proulx wrote:
> > reset >/dev/console
> >
> > Although I can't remember if tset or reset operate on stdin like stty
> > does. You might need to redirect stdin instead.
> >
> > reset >/dev/console </dev/console
By experimentation (I should just pull the source and look) I deduce
that reset operates on stderr. Because I assumed it would write
escape sequences to the terminal. This was my experiment.
$ reset 2>&1 | od -tx1 -c
0000000 72 65 73 65 74 3a 20 73 74 61 6e 64 61 72 64
20
r e s e t : s t a n d a r d
0000020 65 72 72 6f 72 3a 20 49 6e 76 61 6c 69 64 20
61
e r r o r : I n v a l I d a
0000040 72 67 75 6d 65 6e 74 0a 0a
r g u m e n t \n \n
$ reset 2>&1 | cat
reset: standard error: Invalid argument
So it only operates if fd 2 stderr is a tty device and not a pipe. It
must be calling ioctl(2) calls upon fd 2.
> Thanks for the ideas. I've tried both, with /dev/tty1 and /dev/console
> but it didn't change anything. reset seemed to affect the ssh session,
> not the tty so it seems the I/O redirection doesn't do anything there.
I didn't suggest agressive enough redirection because I wasn't
thinking about stderr. Try one more experiment redirecting stderr
too. (But if your inittab experiment didn't work then this probably
won't either.)
reset >/dev/console 2>&1 </dev/console
> Another idea I tried was to insert the reset and stty sane
> commands into the inittab:
>
> 6:23:respawn:/bin/stty sane;/usr/bin/reset;/sbin/getty 38400 tty6
>
> and kill the getty running on tty6. It made no difference when
> testing on VT6 after this.
Clever!
> I think we'll just have to live with a reset via reboot whenever the
> option becomes available, while not removing the PS/2 connections again.
Or perhaps turn on the serial port and use it for a serial console. :-)
Of course that will need a reboot as well in order to tell the kernel
about the different console device. (console=ttyS0,9600n8)
Good luck!
Bob
Attachment:
signature.asc
Description: Digital signature