pseudo-tty conventions

[brnstnd at kramden.acf.nyu.edu]

In article <15618 at frog.UUCP> tdh at frog.UUCP (T. Dave Hudson) writes:
> I received replies from
> 	omerzu at quando.quantum.de
> 	andyb at coat.com
> 	lamy at cs.utoronto.ca
> 	brnstnd at 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