I'd considered that: the multiplexing/TTY sharing stuff would be useful outside the context of loops (or, if you prefer, at least as useful as it is in the context of loops. ) so addressing it as a general mechanism rather than something specific to loops would have advantages, make the shell language more orthogonal, etc.

One approach to doing this would be to have a separate step in which the PTYs and/or pipes are created to serve as /dev/tty, stdout, stdin for various jobs that are going to be run asynchronously: the file descriptors for these could be stored in array variables and passed to the loop construct, which would then pass them on to individual loop steps. Then probably one could come up with other cases where those FD arrays could be useful...

"expect" shouldn't be needed. Probably the sensible default for this "TTY sharing" stuff is to simply not do the TTY sharing thing if there's no TTY. ('course, there would be exceptions - cases where you might want TTY sharing to do its thing even if there's no TTY... If you're displaying the TTYs with xterms, for instance.)

Hm, so is the problem just that people could use this capability to spoof input to programs that interact on /dev/tty?

I can live with that. Anyone who wants to do damage with that kind of capability can do it regardless of whether the shell serves up the functionality or they have to write their own program for it.

Well, yeah, but my aim with "shell threading" is mostly just to keep things from getting booted into a "subshell context" simply because they're occupying a particular position in the command. But I'm starting to feel like it's probably not the best way to go. It'd mean keeping track of all the "threads" that are blocking on something, maybe stuffing all that into a big select() call...

Actually, though (I had to look this up) - it turns out when you fork() in a (Posix) threaded app, the new process has just one thread initially. The threads aren't cloned. So there'd be a little care necessary to make sure the environment's in a usable state prior to calling fork() but otherwise using Posix threads shouldn't be a problem.