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 */
gwyn@brl-smoke.ARPA (Doug Gwyn ) (04/27/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... Although streams are good for a lot of transformations like this, I suspect it would be pretty hard to have a module snatch back data that it has already passed downstream. I would think the whole input canonicalization module would have to be replaced.
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.bob@cloud9.UUCP (Bob Toxen) (05/06/88)
In article <98@skep2.ATT.COM>, wcs@skep2.ATT.COM (Bill.Stewart.<ho95c>) writes: > 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" [For forms.] > # Bill Stewart, AT&T Bell Labs Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcs For forms and such that use raw mode, the System V tty driver's VMIN & VTIME allow you to simulate this without much CPU/code cost. Also, you can specify alternate characters that tell the read() "I got enough, return." Generally, one of these is set to NUL so that BREAKs are handled well. The code fragment illustrates this. [I haven't actually tried the concept or this code.] Permission to steal granted. #include <termio.h> #ifndef VEOL2 #define VEOL2 (VEOL+1) #endif char line[200]; char *p; c_cc[VMIN] = 10; c_cc[VTIME] = 5; c_cc[VERASE] = CTRL(H); c_cc[VKILL] = CTRL(U); c_cc[VEOL] = 0177; c_cc[VEOL2] = CTRL(X); ioctl(these_things); raw_mode(); p = line; loop: switch (*p++ = getchar()) { case CTRL(EOL): p--; if (p > line) { p--; printf("\b \b"); } break; case CTRL(X): while (--p > line) if (p[-1] >= ' ' && p[-1] < 0177) printf("\b \b"); break; default: if (p[-1] >= ' ' && p[-1] < 0177) putchar(p[-1]); } process(); goto loop; -- Bob Toxen {ucbvax!ihnp4,harvard,cloud9!es}!anvil!cavu!bob Stratus Computer, Marlboro, MA Pilot to Copilot: What's a mountain goat doing way up here in a cloud bank?
guy@gorodish.Sun.COM (Guy Harris) (05/07/88)
> For forms and such that use raw mode, the System V tty driver's VMIN & > VTIME allow you to simulate this without much CPU/code cost. Also, you > can specify alternate characters that tell the read() "I got enough, > return." Yes, but you can't do them both at the same time. VMIN and VTIME work in "non-canonical" mode; the two alternate end-of-line characters work in "canonical" mode. In fact, the VTIME element of "c_cc" is the *SAME* element as the VEOL (first alternate end-of-line character) element of "c_cc". There is no form of "non-canonical" mode in the "standard" UNIX tty drivers that also has a "terminator" character. Jack Slingwine put such a mode into the tty driver at Computer Consoles, for the benefit of an intelligent terminal we were using; he added an IBRK bit to the "c_lflag" field, and if it was set you were in a mode where one of VMIN or VTIME worked as it did in non-canonical mode (I forget which one it was) and the other of the two held the "end-of-record" character.