I've already suggested several ways.

I think the argument comes down to this. Yes you can. Yes, you, can.

The main thing you wanted, close-on-exec, is a kernel feature. One ioctl and it's done. The FD isn't just sufficient for it -- it's mandatory.

Any other kind of scoping you could possibly want is still doable too. The shell just has to keep track of it internally, like local variables, instead of crutching it with a "special" variable.

It might be easier for you as the programmer of the language -- on first glance, anyway -- to add all these new special kinds of variables, but I think you'll paint yourself into a corner really quickly. And paint other people into a corner besides.

---------- Post updated at 12:37 PM ---------- Previous update was at 12:05 PM ----------

The point is, you don't need to. There's ways of doing what you want without breaking the very concept of a shell variable.

Anyway. Of course, you could just add an & to the end of that to get what you want, but I think I know what you're getting at. I've thought about that a fair bit myself, and noticed the same problems.

One possible solution, I think, would be pipes. Instead of giving everything a raw stdin/stdout, give them pipes. The shell will read and print output from their stdout pipes in order to enforce proper order of their outputs that way. Completely silent commands will run completely parallel. Ones that aren't might still accomplish some work before the pipe blocks. (You could use temp files instead of pipes for stdout to make a larger 'buffer'.)

stdin would work similarly. As long as process #1 is alive, the shell feeds stdin input into its input, and only moves on to process #2 once process #1 dies. There might also be situations where you'd want it to work in a round-robin fashion, first line going into process 1, second line into process 2, third into 3, fourth into 1, etc, etc.

Interactive commands wouldn't work right, but that goes without saying. To make interactive commands work in parallel, each one would need their own independent virtual terminal -- which is possible but the CPU costs of that could start adding up.

You don't need screen to do that, by the way. Any C program can create a PTY.

I'm not exceptionally concerned about running mounds of interactive things in parallel, really. Usually that doesn't make sense. Things you might want to do that to, like ssh, have anticipated this and have noninteractive mechanisms to accomodate this. For really badly thought-out applications, or things which really, really demand a real human be there, we have the expect language -- a last resort, as it should be.

Synchronizing variables would be more of a problem. I'm not 100% sure how it'd work yet, but I can envision the shell processing a set of lines and compiling an order of operations that it shoves into a queue(okay, these four processes all set this variable once, and the thing below this loop reads it once, so let the loop finish before reading this variable...) ...then following it lock-step to give each operation. It helps that these aren't processes, but always shell syntax or program output fed into shell syntax. A program's never going to do an end-run around us and set a shell variable with a system call or anything. Maybe something like a semaphore, keeping a use-count that unlocks it once there's nothing behind you in line using it... Reading or setting a variable means waiting your turn, reading or writing to stdout means waiting your turn, anything else lets you scream on ahead.

wget can print progress to non-terminals, it just prints lines of dots.

ls is also one of these special commands. When it prints to a terminal, many implementations can print multiple columns, but they switch to single-column output when the output isn't a terminal.

In both cases the output is useful either way when the thing reading them is a script instead of a human, so I don't think it's too important.