curt@nynex1.UUCP (Curtis Villamizar) (09/02/88)
In article <12016@steinmetz.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes: > one of the few things I like about DOS and VMS is that the >characters are echoed as they are read, not as they are typed. This >prevents display of info designed to be read "no echo." Fortunately >there seems to be no reason why this can't be done in a device driver, >even if it's not (I would like to think it is and I haven't found it). Actually you would want to implement this as an alternate line disipline in most Unix versions. I had done that in a past life (while employed by Perkin Elmer) for IDRIS, a V6 look-alike, on a 68000 based computer, and for Sys III on the same toy. (PE still sells the system with IDRIS, bundled in turnkey scientific instrument systems (which required real time enhancements - (which was the real fun stuff))). The line dicipline allowed "delayed echo" to be turned off - a lot of people prefer that. The real advantage of delaying echo is input gets put on the screen where it belongs, not where the cursor happened to be when the character was typed. This is a plus for "cooked" mode applications which use cursor movement. The "new tty" line dicipline on my Sun which I presume either Berkley or Sun did is an example of an alternate line dicipline. When I go back to Sys V, I am always annoyed when it backspaces over my prompt and does other stupid things. This kind of code gets put in the line dicipline once, and can be used with any device driver (including pty's). I think this would be done in a streams layer on Sys V.3 but I'm not sure. Does anyone know if line diciplines are obsolete and replaced by streams stuff? --------------------------------------------------------------------------- Curtis Villamizar <curt@nynexst.com> NYNEX Science & Technology !decvax!{bellcore,linus!philabs}!nynex1!curt 500 Westchester Avenue White Plains, NY 10604 (914) 683-2318 ---------------------------------------------------------------------------
guy@gorodish.Sun.COM (Guy Harris) (09/03/88)
> The real advantage of delaying echo is input gets put on the screen where > it belongs, not where the cursor happened to be when the character was typed. > This is a plus for "cooked" mode applications which use cursor movement. It's worth noting that boatloads of applications that run in "full-screen" mode, such as many popular screen editors, give you delayed echo as a result of turning the kernel's echoing off and doing the echoing themselves. > The "new tty" line dicipline on my Sun which I presume either Berkley or Sun > did Berkeley. > I think this would be done in a streams layer on Sys V.3 but I'm not sure. It's not; S5R3 has streams, but doesn't use them for ttys (except maybe in some cases). > Does anyone know if line diciplines are obsolete and replaced by streams > stuff? In SunOS 4.0, they are; I don't know of any other UNIX version has completely tossed out the "old"-style tty driver and line discipline mechanism in favor of streams-based drivers and modules. The SunOS version offers a superset of the S5 "ioctl" interface, with an additional streams module to translate V7 and BSD "ioctl"s into the new ones; it also has the BSD-style user-interface improvements you alluded to (such as handling "CRT erase" correctly).
woods@gpu.utcs.toronto.edu (Greg Woods) (09/03/88)
In article <397@nynex1.UUCP> curt@chaos.UUCP (Curtis Villamizar) writes: > The real advantage of delaying echo is input gets put on the screen where > it belongs, not where the cursor happened to be when the character was typed. > This is a plus for "cooked" mode applications which use cursor movement. This can be up to the application if desired. All that is required is that the application set noecho, and echo when it actually reads input. You certianly don't have to be in raw or cbreak mode for this to work. If you can't write a fix for the line discipline, why not write a simple front-end for the shell that does the above? (I know, it won't fix echoing anywhere else, but I find I usually typeahead only in the shell (or an editor which is doing it's own echoing anyway!).) > The "new tty" line dicipline on my Sun which I presume either Berkley or Sun > did is an example of an alternate line dicipline. When I go back to Sys V, The 4th BSD tty(4) man page from May 19, 1986 describes new tty. > I am always annoyed when it backspaces over my prompt and does other stupid > things. This kind of code gets put in the line dicipline once, and can be > used with any device driver (including pty's). Does anyone know if the newtty line discipline is ALL Berkeley code? Except for the job control features, it shouldn't be too hard to graft it into termio. > I think this would be done in a streams layer on Sys V.3 but I'm not sure. > Does anyone know if line diciplines are obsolete and replaced by streams stuff? There is usually a STREAMS module that does the same job as a line discipline (called "CANONPROC" in the "Streams Primer"). In Release 3.0, STREAMS isn't used by the tty drivers in general. I understand that in Release 3.1, tty's may be STREAMS based, but aren't necessarily so. With Release 3.1 for the 3B computers, there are three line disciplines supplied. One for tty's, one for xt's, and one for sxt's. I'm not sure of the differences, though I only skimmed the driver manual, so I may have missed the descriptions. The Release 3.1 termio(7) page should describe them, unless they've been given their own pages :-). One thing about STREAMS that bugs me is that the raw drivers must be re-written. It's necessary, but annoying. I wonder if you could write a STREAMS module that faked itself as a process so that it could call an old-style driver.... CALL FOR CODE: If anyone has written any STREAMS drivers or modules, and would be willing to post them, please do (in the appropriate newsgroup). When I get the time, I'm going to start writing fun stuff myself. I'd also be interested in hearing from anyone with code for job control in SysV. Anyone with TLI interface modules for IBM-NETBIOS, and drivers for the IBM token-ring card, please give me a call! We're ready to pay cash! -- Greg Woods. UUCP: utgpu!woods, utgpu!{ontmoh, ontmoh!ixpierre}!woods VOICE: (416) 967-3096 [w] (416) 242-7572 [h] LOCATION: Toronto, Ontario, Canada
gwyn@smoke.ARPA (Doug Gwyn ) (09/03/88)
In article <397@nynex1.UUCP> curt@chaos.UUCP (Curtis Villamizar) writes: >Does anyone know if line diciplines are obsolete and replaced by >streams stuff? Streams started out as "stackable line disciplines". To replace a line discipline, one would pop the old one and push a new one. Thus, in theory streams is a generalization that replaces the old notion of line disciplines. However, for purposes of compatibility, the terminal handler streams module may still support the old method internally. One might think that each orthogonal terminal handler feature would be controlled by a separate streams module, but that's not how it has been implemented. So to change echo behavior you'd have to provide a whole alternative terminal handler module.
gwyn@smoke.ARPA (Doug Gwyn ) (09/03/88)
In article <66798@sun.uucp> guy@gorodish.Sun.COM (Guy Harris) writes: >S5R3 has streams, but doesn't use them for ttys (except maybe in some cases). I thought SVR3.1 or perhaps SVR3.2 had finished the conversion of the character I/O system to use STREAMS.
levy@ttrdc.UUCP (Daniel R. Levy) (09/04/88)
In article <8420@smoke.ARPA>, gwyn@smoke.ARPA (Doug Gwyn ) writes: < Streams started out as "stackable line disciplines". To replace a line < discipline, one would pop the old one and push a new one. Thus, in < theory streams is a generalization that replaces the old notion of line < disciplines. However, for purposes of compatibility, the terminal < handler streams module may still support the old method internally. < < One might think that each orthogonal terminal handler feature would be < controlled by a separate streams module, but that's not how it has been < implemented. So to change echo behavior you'd have to provide a whole < alternative terminal handler module. Or, what about implementing the "better" scheme yourself, and provide, not a single monolithic replacement terminal handler, but a number of sub-handlers each of which controls each orthogonal feature etc.... Might this, however, lead to potential performance problems? -- |------------Dan Levy------------| THE OPINIONS EXPRESSED HEREIN ARE MINE ONLY | Bell Labs Area 61 (R.I.P., TTY)| AND ARE NOT TO BE IMPUTED TO AT&T. | Skokie, Illinois | |-----Path: att!ttbcad!levy-----|
baur@spp2.UUCP (Steven L. Baur) (09/04/88)
in article <1988Sep2.224258.27960@gpu.utcs.toronto.edu>, woods@gpu.utcs.toronto.edu (Greg Woods) says: > Checksum: 60337 > > In article <397@nynex1.UUCP> curt@chaos.UUCP (Curtis Villamizar) writes: > >> I am always annoyed when it backspaces over my prompt and does other stupid >> things. This kind of code gets put in the line dicipline once, and can be >> used with any device driver (including pty's). This is dependent upon what shell you are using. If were using ksh, you would not notice this problem. Sh will willing backspace over the prompt even on BSD systems. steve
gwyn@smoke.ARPA (Doug Gwyn ) (09/05/88)
In article <1402@spp2.UUCP> baur@spp2.UUCP (Steven L. Baur) writes: >Sh will willing backspace over the prompt even on BSD systems. Not true. BSD /bin/sh is invariably run in "cooked" mode, where the terminal handler takes care of such things as character erasing. And the "new" BSD terminal handler, which is the only one anyone in his right mind uses on BSD, does not erase past the beginning of the input. When history/command editing is enabled in the BRL sh, characters ARE individually read and acted on immediately, same as the Korn shell. We also don't backspace before the beginning of the input. (At present we also don't emulate line wrap for terminals that lack it, because we don't want the shell to have to depend on termcap.)
bzs@encore.UUCP (Barry Shein) (09/05/88)
>This is dependent upon what shell you are using. If were using ksh, >you would not notice this problem. >Sh will willing backspace over the prompt even on BSD systems. > >steve That's just false. You are just seeing the behavior of the terminal driver in cooked mode which may (BSD) or may not (SV) be counting erase chars and stopping when it's all gone. It's possible some shell version uses cbreak mode to emulate correct erase echoing but my experiments with ksh here found what I expected, it simply depends on the behavior of the underlying terminal driver. -Barry Shein, ||Encore||
dce@mips.COM (David Elliott) (09/05/88)
In article <1402@spp2.UUCP> baur@spp2.UUCP (Steven L. Baur) writes: >>> I am always annoyed when it backspaces over my prompt and does other stupid >>> things. This kind of code gets put in the line dicipline once, and can be >>> used with any device driver (including pty's). > >This is dependent upon what shell you are using. If were using ksh, >you would not notice this problem. >Sh will willing backspace over the prompt even on BSD systems. Actually, it's dependent upon which shell, how the shell is configured, and which tty driver you are using. Shells with line-editing (ksh, tcsh, BRL sh, etc.) use some sort of canonical tty mode and can keep track of the current position on the line (even with respect to tabs, if they so desire). Shells without (csh, sh) or line-editing shells with the line-editor turned off let the tty driver do the work. What you describe above (backspace over prompt even in BSD) is a by-product of the tty driver, not the shells. In other words, it's only affected by the shell because the shell tries to emulate a smart tty driver, and it's only affected in the shell (i.e., you can still backspace over a debugger prompt). -- David Elliott dce@mips.com or {ames,prls,pyramid,decwrl}!mips!dce
guy@gorodish.Sun.COM (Guy Harris) (09/06/88)
> >S5R3 has streams, but doesn't use them for ttys (except maybe in some > >cases). > > I thought SVR3.1 or perhaps SVR3.2 had finished the conversion of the > character I/O system to use STREAMS. Nope, at least not in the S5R3.2 code we have, and definitely not in S5R3.1.