separate the command language and interactive she

[John R. MacMillan]

|Teaching the front-end about all this gets ugly.

I agree.

|The simplest way to handle completion is to have a communication
|channel between the front-end and the current interactive process.
|(Which immediately has two problems in Unix: What's the "current
|interactive process"?  How do I talk to it?  (So how do we fix Unix?))

Again, agreed.  I think your two questions are interrelated.

If we use stdin/stdout as the communications medium, it's easy,
portable, and the current interactive process is the one that is
reading the other end.  Eg. ish starts sh, sh is current.  Sh starts
gdb, so is waiting, gdb is reading, so it is current.

The big drawbacks to this mechanism are that a non-cooperative program
may just happen to look like a cooperative one on stdout, and that the
communication is either visible to the user, or must be hidden by the
programs (and again, you could accidentally hide something that just
happened to look like communication).

If this method is not acceptable, some other IPC mechanism must be
used.  Sockets on BSDish systems, and one or two of the too-numerous
SysV IPC mechanisms would seem the obvious choices.  In this case, the
cooperating processes could negotiate who the current interactive one
is over the IPC mechanism (sh relinquishes its status when starting
gdb, and gdb asserts itself as the current interactive process).