eirik@tekcrl.TEK.COM (Eirik Fuller) (02/12/88)
Recently, I have been making fairly extensive modifications to X10's xterm. One of my mods this week seems so right to me that I thought I should bounce it off others, just to find out what's wrong with it. I have been unsubscribed to this group for some time, so for all I know this topic is old hat. Please, use email for all flames, supplemental ideas, arguments, pointers to pre-inventors, etc. If I get enough interesting responses, I'd be happy to post a summary if appropriate. My goal for this mod was to have my workstation (a Tek 4315 running UTek (a mutation of 4.2), if it matters) wake up in X in a "reasonable" way. My notion of reasonable means I see at least one terminal window with a login prompt on the familiar X background. At first glance, the -L option looked like a possibility, but it had problems for which I am about to describe my solution. I'll leave out my reasoning for brevity; my conclusion after a frustrating series of experiments was that gettys are supposed to be fork/exec'd by init, and that I shouldn't try to change that. The problem that left me with: what if someone else opens the master side of a pty I've turned on (in /etc/ttys)? Not quite what I want. The solution was easy: prevent anyone from opening the master side of said pty. How? Replace (for instance) /dev/ptyp0 with a dummy; UTek has a device called nodev which stats but doesn't open; simply removing it might be ok too, but would probably trip up a pty loop that exits when a stat fails. Rename this master side to (for instance) /dev/xtyp0. Modify xterm so that with the -L option (which now takes no argument) it scans not for /dev/pty[p-s][0-9a-f], but for /dev/xty[p-s][0-9a-f], when seeking a master. Ignore the slave side, and skip the fork/exec. In other words, xterm -L opens the master side of a reserved pty, and leaves it to something else (like init) to open the slave. This isn't speculation; one of my UTek boxes wakes up this way, and it works like a charm (I haven't rebooted the other since, or it would by now too). I can even put a menu item on a (fairly restriced) uwm running as root to open additional login windows, until there are no more reserved ptys left. How to get rid of such windows is a question I haven't addressed in detail yet, but a single immortal login window serves my purposes nicely, so I haven't had to deal with it. What I like about this approach: the set of reserved ports is completely recorded in the state of the file system. /etc/ttys tells which network ports have gettys; /etc/ttytype says they are all xterms; /dev has entries mknod'd in a manner consistent with all this. Nothing in the mechanism prevents similarly reserved ports for other purposes; simply use a different naming convention for the master side, and fix the terminal type accordingly. I don't mean this to lead into a discussion of whether a window should go away after I logout, or whether there should be a graceful exit from the X server (besides /etc/shutdown). I don't run other windowing systems on 4315s, unless you count smalltalk, which runs under X (in a manner of speaking; I don't need to leave X to run it). I'm just offering this as an idea, wondering why nobody else has expressed it (for all I know, someone has; like I said, I've been unsubscribed for some time), and what problems it might cause. Please, reply via email, not followup postings; I'll summarize if appropriate. eirik%crl.TEK.COM@relay.cs.net ARPA incantation ...!tektronix!crl!eirik antique address :-)