Submission for comp-unix-microport

[The Daily Fishwrap]

Path: tolerant!voder!apple!bloom-beacon!tut.cis.ohio-state.edu!cs.utexas.edu!ssbn!texbell!egsner!spdyne!root
From: root at spdyne.UUCP
Newsgroups: comp.unix.microport
Subject: Re: Setkey problem...
Message-ID: <1700008 at spdyne>
Date: 4 Jan 89 23:14:00 GMT
References: <1700002 at spdyne>
Lines: 67
Nf-ID: #R:spdyne:1700002:spdyne:1700008:004:2996
Nf-From: spdyne.UUCP!root    Jan  4 17:14:00 1989


>I wrote:
>> 
>> 
>> Greetings,
>> 
>>     I have sent this 8 ways to try to get it into uport... INCLUDING
>> directly connecting to uport!  No response...
>
>My guess is that are in fact not reaching a read account.  Are you using the
>"techs" account or are you going direct?  Microport does reply to mail or
>else they would see a lot more of this type of flame.  (Which was quite common
>not all that long ago.)
>

    Well, I sent it to the following accounts: techs, plocher, jmsully.
    all at uport, with no luck.. (this was a couple of months ago, and
    I was giving them time to respond, not knowing how overloaded their
    time may be...)


>>         1) Login on the console, type setkey f10 "echo hello^M"
>>            Test this by hitting F10, and it will `echo hello'.
>>         2) Login to a normal user account on Cons2.
>>         3) Switch to the console and Hit F10.... Surprise! you get
>>            <ESC>X or something....(an X echos)... it is as if you did
>>            a setkey -d on the console!...
>>      This seems to happen when you login to ANY of the consoles...a real pain
>>      in the ... if you are expecting your function keys to do something
>>      useful.
>
>I feel (as apparently so does Microport) that an ioctl to one console device
>should not affect ALL console devices.  (Just as NDELAY on ttys should affect
>only the tty set with NDELAY and not all ttys or even all fds open to that tty.)
>
>This behavior (albeit not exactly what you had in mind) is correct and should
>stay the way it is.  (How difficult is it to simulate using what is correct
>behavior to make things be the way you want?  My guess is a three line shell
>script.)
>
>Good luck.
>   David F. Carlson, Micropen, Inc.


    Did I miss something here?  You say that executing login on a DIFFERENT
console terminal SHOULD Zap all of the setkey assignments on the console and
every other /dev/cons*?!!?   And the back it up with some sorta bunk about
ONLY affecting the ONE console device that it was executed on??  I don't
understand.  Do you?

    As for the how difficult is it to simulate.. I would have to reexecute
the setkey assignements on the console EVERY time someone loggs into the
virtual console port.  True, I have a command to do this now, but really
I think that it should work AS DOCUMENTED: if executed on the console it
will affect all consoles, if executed on a virt. console, it will affect
ONLY that console.

    After some more checking, I found that if you execute setkey -d on
any console, it will clear all of them.  It seems that the other bug
that I had, namely that reassigning a key that was once assigned causing
it to scramble all of the assignments, no longer is a problem. (Now that
I have upgraded to 3.0E.  To fix the problem with it scrambling the 
assignments, I had a setkey -d in my .login (Before all of the other
setkey's, I have fixed this by only executing setkey on the console.. but..
it still is broken.)

    -Chert Pellett