Quote:
Originally Posted by
Corona688
Quote:
In the design I've suggested here, the shell doesn't take responsibility for fixing that. (TTY sharing in a loop) Rather, it merely provides a mechanism that allows an external program to fix that...
Does that have to be done as part of the parallel loop? That sounds like something you might want to do in general, inside or outside a loop.
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...
Quote:
You end up with shell scripts that require expect to run, and start spewing garbage to stdout if you try to disentangle them.
"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.)
Quote:
Utilities like ssh and su require password input to be from a terminal, but PTY's count. Something that gives you quick and easy access to PTY's, let alone in a high-performance parallel manner, isn't the sort of tool you want to just leave lying around
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.
Quote:
Quote:
(Interpreted languages can implement threading without threads)
That's just timesharing. If you want actual benefits from threading, you must do multithreading and/or multiprocessing.
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.