I'm actually not against that. As long as a variable always acts like a variable, the special cases I keep harping about don't exist. That's the whole point of polymorphism, yes? Lets you use different things the same way?

Perl does a really bad job of polymorphism. It's specialized itself into a big mess of special types and operators that are all context-sensitive. Depending on what kind of variable it is, print $variable, "\n" could print a string, a blank line, a mess of crap, the length of something, a pointer dump like ARRAY(0x123851023), a syntax error, or a host of other things. You can spend hours just trying to figure out what kind of variable someone's perl module hands off to you, let alone how to use it.

The shell has avoided this by keeping the meaning of its operators consistent and only having one interface for variables, strings. ${something} means string. ${#something} means length. ${*} means all arguments. "${@}" means all arguments without splitting on IFS. They work alone or in combinations, on arrays or strings or environment vars or local vars. The shell knows the difference and that's enough. In the few cases you're not allowed to combine them, that's always syntax error, not a silent substitution of nothing, not a length you didn't ask for, not a garbled mess, not a pointer dump. You can always expect to access a shell variable the same way no matter what it is, and the interface is flexible enough to encompass most possibilities. That's polymorphism.

And also why I think expanding the concept of variable instead of tacking the new concept of scoped files onto the side of it would work better. Let the variables be accessed the same way, as strings, since it's already convenient for the programmer, fits nicely with the existing syntax for redirecting files, and wouldn't need huge amounts of surplus new syntax to add. All that needs to be different about the variable is the ability to close a file when it goes out of scope. The scoping doesn't have to be something that causes the programmer to need new syntax to use, any more than a C programmer would use a stack variable differently than a global one.

---------- Post updated at 04:41 PM ---------- Previous update was at 03:52 PM ----------

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. Let the parallel loop be the parallel loop and the TTY sharer be the TTY sharer. That could be confusing if the threads end up doing different things on each iteration. I agree it could be useful but I'm not sure it should be part of the shell script. You end up with shell scripts that require expect to run, and start spewing garbage to stdout if you try to disentangle them. 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 -- another reason expect's a last resort. True, but take a look at the way these features are made. A shell script isn't going to blow up because someone disabled tab-completion -- shell scripts don't use tab completion, that's a user thing. Nor are they going to start typing in pgup to recall the last command and blow up when history features turn out to be unavailable, that's a user thing too. You cannot write scripts depending on these features and that's intentional -- the shell might care if it's in a terminal or not, but the program usually doesn't.

That's what I mean by not building it in, making it something like a debug flag -- to change the behavior of something to let it pop up these little windows. The script doesn't have to know or care whether you're snooping on its threads outputs or not, that can be left up to the shell. After all, what would know better about the current terminal than the shell?
It doesn't have to be all-or-nothing. I think it's possible to make a syntax that's both convenient and general-purpose. Not THAT complicated.

Code:

#!/bin/bash

THREADS=5       ;       WAIT=0  ;       END=0

# Wait for next thread.
function waitnext
{       # Needs BASH/KSH
        wait "${PIDS[$(( (WAIT++) % THREADS))]}"
}

for ((N=0; N<100; N++))
do
        [ "$((END-WAIT))" -ge "$THREADS" ] && waitnext
        sleep 1 & PIDS[$(( (END++) % THREADS ))]=$!
done
# wait for ALL remaining processes
wait

There's a shell feature missing that'd make this better and easier -- the ability to wait for any one process without saying which one. Right now you have a choice between waiting for one specific process or waiting for all of them. [edit] Or trapping SIGCHLD. That'd work, but would work better if shell had something like semaphores

That's just timesharing. If you want actual benefits from threading, you must do multithreading and/or multiprocessing. Kind of what i said but in more detail It is, and could cause other problems. If the parent closes a file descriptor, this child launcher will have to follow its lead somehow.

There's a better way to do this but I don't quite remember it. Something to do with fork callbacks. ...What? Really?

That's perfect for scoping your files! Allow local variables in braces like that. Your files could be some of these variables, containing FD numbers. When they go out of scope, the files close.