ken@cs.rochester.edu (Ken Yap) (04/19/88)
Not a bug really, but I wish tset would accept both DEL and BS as erase for answering terminal type queries. I don't think we are likely to see terminal types of vt2<BS>100 in /etc/termcap. Ken
gerry@syntron.UUCP (G. Roderick Singleton) (04/22/88)
HUH? My manpage says that tset will set kill, intr and erase correctly and
I confirm that it behaves as advertised. However, I'm uncertain whether that
is what you mean, could you expand please?
ger
--
G. Roderick Singleton, Technical Services Manager
gerry@{ syntron | geac | eclectic }.UUCP
"ALL animals are created equal, BUT some animals are MORE equal than others."
George Orwellken@cs.rochester.edu (Ken Yap) (04/25/88)
OK, novice user logs on and is unaware that the default erase char on his system is <DEL>, or worse still, #. Sees this: TERM = (vt100)? No, I'm on a Teleray, he says and proceeds to type t1061. He types 2 for 1, realizes the error and backspaces over it. Tset gets "t2<BS>1061", can't find this in /etc/termcap and prints "unknown terminal type: t1061" and now the user is really confused. Usually they have to logout at this point and retry, since they don't know that they can say "source .login" and that isn't foolproof always. My proposed solution: get tset to go into raw mode and accept both <DEL> and <BS> as erase. Also probably both ^X and ^U as kill. After all, tset is usually the first program novices have to deal with. Ken
art@felix.UUCP (Art Dederick) (04/26/88)
In article <8948@sol.ARPA> ken@cs.rochester.edu (Ken Yap) writes: >My proposed solution: get tset to go into raw mode and accept both ><DEL> and <BS> as erase. Also probably both ^X and ^U as kill. How about just putting this before the call to tset: stty erase ^H kill ^U Or whatever is the most common. This has worked ok on all machines I have ever been on. Maybe the best solution is to make <BS> the default erase character. I don't know about you but I have not used a TTY for over 10 years :-). Art D.
gnu@hoptoad.uucp (John Gilmore) (04/27/88)
ken@cs.rochester.edu (Ken Yap) wrote: > Not a bug really, but I wish tset would accept both DEL and BS as erase > for answering terminal type queries. Stanford actually implemented two erase characters in the Unix tty driver. I think this is a great idea. You can set it so that both BS and DEL will erase a character, in all programs, not just those that have been jiggered like Ken proposes for "tset". For some reason, people at Berkeley and Sun did not like this change and it is still a local Stanford thing. Maybe with streams tty drivers even we binary customers will be able to write a little module that will support a second erase character and push it onto the stream...until we finish GNU and have full source. The tty support in any OS is such a mass of dealing-with-idiosyncracies that I'm surprised that people want the humans, rather than the computers, to keep having to deal with the BS versus DEL idiosyncracy. -- John Gilmore {sun,pacbell,uunet,pyramid,ihnp4}!hoptoad!gnu gnu@toad.com /* No comment */
paul@morganucodon.cis.ohio-state.edu (Paul Placeway) (04/28/88)
In article <4493@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes:
< Stanford actually implemented two erase characters in the Unix tty
< driver. I think this is a great idea. You can set it so that both BS
< and DEL will erase a character, in all programs, not just those that
< have been jiggered like Ken proposes for "tset". For some reason,
< people at Berkeley and Sun did not like this change and it is still a
< local Stanford thing.
From the other things I have heard, this is typical Berkeley. Another
example is the CMU detachable ptys (a _really_ good idea): basically a
given pty is not hard-associated with the _same_ tty, but can be
assigned to an arbitrary free one (or one you allready own). This
allows the user to hang up one terminal, and go to another and continue
the login session. Naturally, since it was not invented at Berkeley, it
didn't make it into the distributions. *sigh*
For terminals, I think that all of the flavors of Unix have been going
about key function binding all wrong. Unix should not bind keys to
functions, but rather functions to keys: have a per-character table,
each entry of which tells the tty driver which function to run for that
key. (Sound like Emacs?) Among other things this would be faster,
because the driver would not have to search through a list of 7-14 (or
so) functions for each key.
Now this would require more memory per tty (like 256 bytes), but then
again most Unixes are runing on machines that are somewhat bigger than
PDP-11s...
-- Paul
-=-
Existence is beyond the power of words
To define:
Terms may be used
But are none of them absolute.dsc@izimbra.CSS.GOV (julie's working for the drug squad) (04/28/88)
In article <11797@tut.cis.ohio-state.edu> paul@morganucodon.cis.ohio-state.edu (Paul Placeway) writes: >the login session. Naturally, since it was not invented at Berkeley, it >didn't make it into the distributions. *sigh* i can't answer why berkeley did not accept the pty changes you mentioned or the ones to tset that john did, but i think you are wrong on this count. one of the interesting things about 4.3 (as well as 2.10) is how much of the software was contributed by individuals not associated with the university. i don't think the folks at the `csrg' are afraid or adverse to integrating changes done elsewhere, as they have done so many times (of course, henry at utzoo may have some related thoughts on the matter :-) why not send mail or talk with some of the folks there about the changes in question and find out specifically why the changes were not used. sigh ... followups to alt.flame, dsc
wcs@skep2.ATT.COM (Bill.Stewart.<ho95c>) (05/04/88)
In article <4493@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes:
:Maybe with streams tty drivers even we binary customers will be able
:to write a little module that will support a second erase character
:and push it onto the stream...until we finish GNU and have full source.
One feature I've wished was available in a TTY driver is the ability to
specify a bunch of characters (e.g. control characters), and tell it
to "read until N input characters or a special character". This would
make it much easier to do form and menu applications efficiently.
Streams provides one way to do it, but it would be nicer to keep it
down in the I/O hardware if possible. You couldn't do it on the old
4K RAM KMC-11's , but most modern RS232 boards have 64K storage or more.
--
# Thanks;
# Bill Stewart, AT&T Bell Labs 2G218, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcs
# skep2 is a local machine I'm trying to turn into a server. Please send
# mail to ho95c or ho95e instead. Thanks.aglew@urbsdc.Urbana.Gould.COM (05/08/88)
>For terminals, I think that all of the flavors of Unix have been going >about key function binding all wrong. Unix should not bind keys to >functions, but rather functions to keys: have a per-character table, >each entry of which tells the tty driver which function to run for that >key. (Sound like Emacs?) Among other things this would be faster, >because the driver would not have to search through a list of 7-14 (or >so) functions for each key. > >Now this would require more memory per tty (like 256 bytes), but then >again most Unixes are runing on machines that are somewhat bigger than >PDP-11s... If I remember correctly Mike "der Mouse" Parker at McGill has done this. I think that it takes 512 bytes - it's nice to be able to store flags for special actions like erase, etc. Mouse, d'you read this newsgroup? Andy "Krazy" Glew. Gould CSD-Urbana. 1101 E. University, Urbana, IL 61801 aglew@gould.com - preferred, if you have MX records aglew@xenurus.gould.com - if you don't ...!ihnp4!uiucuxc!ccvaxa!aglew - paths may still be the only way My opinions are my own, and are not the opinions of my employer, or any other organisation. I indicate my company only so that the reader may account for any possible bias I may have towards our products.