brnstnd@kramden.acf.nyu.edu (06/13/90)
In article <15618@frog.UUCP> tdh@frog.UUCP (T. Dave Hudson) writes: > I received replies from > omerzu@quando.quantum.de > andyb@coat.com > lamy@cs.utoronto.ca > brnstnd@stealth.acf.nyu.edu > All of these used different schemes, presumably all of which break > would-be-portable code. You can integrate my pty program gradually into your current environment, without changing any old programs. In other words, it doesn't break any portable BSD code. Of course, any new code that uses pty can take advantage of its security, disconnectable sessions, and full efficiency even after a reconnect. As an example, I included in the pty package some patches to the latest telnetd. Under the patched version, any login shell is disconnectable by default. Furthermore, you get the same I/O efficiency as the pre-patched telnetd. And all this is practically invisible to the users. [ Sequent/DYNIX pty naming convention ] > Comments: > This allows for 992 ptys. I also like the idea of > encapsulating the allocation of ptys. I also like modularity, to the extent that pty is an entirely separate program that you can easily reconfigure without recompiling any other code. You can also use it in shell (or perl) scripts, or from the command line (remember the ``condom'' discussion not long ago?). One of the biggest advantages of this system is pty security, which you simply can't achieve any other way. (Witness Sun's idiotic mode 666 /etc/utmp.) Note that pty provides full support for programs that need direct control over the master side of the terminal. The latest telnetd, for example, supports Linemode; even though it lets pty do all the pseudo-terminal allocation in a separate process, it retains the control necessary to pass terminal ioctls through the network. > 4) Dan Bernstein's pty program > Naming convention: > /dev/[pt]ty[p-za-o][0-9a-f] > (but with PTY1 and PTY2 ranges in Makefile) > Allocation convention: > Dan is writing a UNIX-domain sockets daemon for > allocating pty descriptors, and would re-write for > streams. Ummm, those are just future internals for better support of more modern systems. Right now the code should be easily portable to any BSD 4.2 or 4.3 system. Anyway, the *interface* is what matters: to run program foo under a pseudo-terminal session, you just run pty foo. > Comments: > This allows for at least 416 ptys. Dan claims that > under a /dev/[pt]typ<decimal#> scheme "[m]any > utilities will die horribly if tty extensions are > larger than two characters", but I don't see how any > scheme here wouldn't fail to be portable. Hmm? Although I include public-domain clones of various utilities in the pty package (including a script that *works*, can be suspended, uses /etc/utmp correctly, etc.), pty supports the same old BSD convention of /dev/ptyxx. So old accounting programs that read utmp or wtmp don't have any problem working with pty. That ``scheme'' sure is portable. Anyway, /dev/pty[a-zA-Z0-9][a-zA-Z0-9] gives you nearly four thousand ptys to play with (provided you configure them all into your system). You change one line in pty's Makefile to support this. Note that pty has an option for searching through ptys randomly, so it won't get slower and slower and slower like most pty-allocating programs. > There seem to be no widely accepted pty conventions. I'd like to see > some discussion before deciding what conventions to use. I recommend not using a particular convention at all. Assume that there is another program, ``pty,'' with a reasonably standardized interface. Just stop worrying about the internals. Oh, yeah, the current pty submission to c.s.unix is available upon request or via anonymous ftp to the new archives at stealth.acf.nyu.edu (128.122.128.22). pub/pty.3.0.shar. ---Dan