richard@aiva.UUCP (10/30/87)
[In a discussion of output pagination in comp.arch...] In article <705@its63b.ed.ac.uk> simon@its63b.ed.ac.uk (Simon Brown) writes: >Unfortunately, it isn't (so far as I know) possible to detect tty-mode changes >over a pty, which means that the paging could *not* be automatically disabled >if the command puts the terminal (ie, the slave end of the pty) into raw or >cbreak mode, which wouldn't be the best at all. Yes, this is something I've found awkward. I wanted to write a program that would provide command line editing in the style of tcsh (or indeed Simon Brown's ssh) for all programs. This would be done using a pseudo-terminal and a filter program. However, the inability to detect cooked-raw-cbreak mode changes means this won't work if you want to be able to use screen editors and the like. In fact, it is possible to detect mode changes sometimes - a pseudo terminal in packet mode can detect when the slave end flushes input, which usually happens when changing modes (NB this is all BSD-specific). What would be really useful would be a device that merely passed everything from its slave end to its master end, including ioctls. Ioctls calls at the slave end would (optionally? - certainly in the case of GET ioctls) suspend until the master end had processed it. Has any unix system had such a device? As well as the paging/editing applications, it could be used for prototyping other device drivers; much of the debugging could be done with the driver in user code, rather than the kernel. I did, in fact, write such a device driver and used it on a sun to run suntools in a window and across the network. Response was, of course, quite abysmal. As this has little to do with computer architecture, I'm redirecting followups to comp.unix.wizards. -- Richard Tobin, JANET: R.Tobin@uk.ac.ed AI Applications Institute, ARPA: R.Tobin%uk.ac.ed@nss.cs.ucl.ac.uk Edinburgh University. UUCP: ...!ukc!ed.ac.uk!R.Tobin
chris@mimsy.UUCP (Chris Torek) (11/01/87)
In article <186@aiva.ed.ac.uk> richard@aiva.ed.ac.uk (Richard Tobin) writes: >... What would be really useful would be a device that merely >passed everything from its slave end to its master end, including >ioctls. Ioctls calls at the slave end would (optionally? - >certainly in the case of GET ioctls) suspend until the master end >had processed it. (Any ioctl that receives an answer suspends; hence all ioctls suspend: every ioctl gets at least a success/fail answer.) >Has any unix system had such a device? Version 7's (Greg Chesson's, if I recall aright) multiplexed files did this. They had a number of problems, but most of them were due to the implementation. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
rml@hpfcdc.HP.COM (Bob Lenk) (11/05/87)
> What would be really useful would be a device that merely passed everything > from its slave end to its master end, including ioctls. Ioctls calls at the > slave end would (optionally? - certainly in the case of GET ioctls) suspend > until the master end had processed it. Has any unix system had such a device? HP's implementation of ptys includes extensions to permit the master side to trap and/or process open, close, and ioctl requests from the slave side. Bob Lenk {ihnp4, hplabs}!hpfcla!rml
bbaker@nprdc.arpa (Burt Baker) (11/29/88)
I'm trying to use a pseudo-terminal to talk to an IPC socket. Can anyone help me with the psuedo-terminal, that is, provide me with some code ? thanks in advance ..... Burt Baker (bbaker@nprdc.arpa !ucsd!nprdc!bbaker) NPRDC San Diego, CA.