Quote:
Originally Posted by
tetsujin
"expect" shouldn't be needed.
I meant screen, sorry. Probably doesn't change the answer though.
Quote:
Probably the sensible default for this "TTY sharing" stuff is to simply not do the TTY sharing thing if there's no TTY.
But where would the output go instead?
Quote:
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.
Sure, if given access to them. Just something to keep in mind.
Quote:
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.
External commands
have to be in a seperate context. There's just no other way to run them. Builtins could be run in threads, so wouldn't need a separate context.
Even if you fork(), it's possible to share memory by other means. Memory you've created with mmap() can be shared between such processes. So just being in a subshell doesn't mean you'd have to lose access to variables.
Environment variables though come preallocated so can't be shared that way without torturing your process environment in cruel and unusual ways.
Some builtins, like
echo, might not need
any context. When you know the amount of text is smaller than the size of your pipe, you know it'll never block -- so just cram the text in the write-end and close the write-end in advance. You don't need a new thread just to do that.
Quote:
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...
Why not let the mutexes do the blocking?
Quote:
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.
Reference, please? Things I've seen suggest quite differently. Then again, that's something I saw
inside the linux pthreads library, so that might be things they had to do to prevent threads being cloned rather than things I'd have to do...
If true, that
would make it a ton easier.