Maybe there's a better way I can explain myself. I originally started programming in gwbasic.

Code:

LET B=1
PRINT "Okay, B is " + B

Almost immediately I wanted to feed PRINT's output into a string. There's no direct way to do it. I ended up saving its output into a file then reading it back, which worked.

Eventually I graduated to quickbasic, which let me make subroutines. Out of curiosity, I tried to see if I could make my own PRINT.

Turns out, you can't. Print's a builtin, which makes it "special".
You can't have a variable that does anything either, even though there are some are kludged into in BASIC as builtins -- like DATE$, which sets the date. (and causes havoc for vbscript writers who aren't aware of this behavior.)

Later I tried to make a subroutine that evaluated expressions. Not flexible enough. What I eventually had to do was convert the expression it was fed into a .BAS file, and execute another instance of qbasic to evaluate it. Basic's not orthogonal: You can't use the things you build for it the same way you can use the things that're built in.

Even the worst Bourne shell makes these problems almost trivial, because -- for all its faults -- the Bourne shell is very orthogonal. There's almost no corners where environment vars, global vars, local vars, files, strings, builtins, aliases, functions or external programs have to be used in one particular way over another, and it can feed its own output and expressions back into itself seamlessly and Do The Right Thing(tm).

Now imagine it had three mutually exclusive ways of handling things -- one for stdin and stdout, one for all other files, and one for strings. By building those things as independent features you've inadvertently built walls between them which programmers will be hitting like grasshoppers on your windshield unless you kludge bridges over them somehow.

In a strongly typed language, that's easy. It doesn't have to decide on the fly what routines to use, and can even warn you if you mix and match them in problematic ways.

In the shell it's still doable because they can all be stored as strings. With some work you can still keep it orthogonal, make it do the right thing under any circumstances -- so there's not a conflict.

Files would be a whole new kettle of fish. Suddenly variables are special things that might be strings, might be files, might be syntax errors, might be I/O errors, or might just block. Everything gets more complicated.

How about a new special character like @filehandle? Then you won't get files showing up in places you didn't expect. I wouldn't go too overboard like Perl did, but just one shouldn't end the world. If you're inventing a totally new language, I wouldn't just extend a shell, I'd rip out a ton of old stuff too.

Which syntax for arithmetic do you prefer?

Code:

# old-fashioned hack
C=`expr $B + 5`
# good old-fashioned BASIC
let A=B+5
# newer C-like
((C=B+5))

etc, etc, etc. There's tons of redundancy that could be stripped out.

Almost anything but pipes could be revamped. I know you'll be tempted to turn <file into an anonymous filehandle instead of stdin, but consider how many programs read from stdin and you might want to keep stdin/stdout as easily available as they are already.

Another neat operator could be something like @*.txt | command ...to make shell globbing print to stdout, like find doues. Argument limit, what argument limit? What is the difference between an ordinary file and a special file? Presently, nothing -- which is extremely nice. Remember you're building a language which people other than you will use. If you don't allow possibilities you didn't think of, users can't program in ways you didn't think of. I think you just have a lot more to learn about it. Arrays translate very nicely and usefully into strings.

Code:

$ A[0]=1
$ A[1]=2
$ A[2]=3
$ IFS=","
$ echo "${A[*]}"
1,2,3
$

...which you can also use backwards:

Code:

$ IFS=","
$ STR="a,b,c"
$ A=( $STR )
$ echo "${A[0]}"
a
$

This was in BASH but should work in KSH too. Even an associative array will work. "It's very common to print to the screen, or maybe a file. But who'd ever want to print to a string?" That line of thought left a huge hole in the BASIC language that had to be kludged around. Don't forget the read builtin. Also, the linux flock utility. Also don't forget how any program taking a filename can get /proc/self/fd/23 shoehorned into it. Or you can just redirect anything you want into stdin. Once again, the shell's flexibility is key.

Getting rid of that feature wouldn't be a problem for most of my shell scripts. But it would be impossible to write a few small but really important ones. That's a self-fulfilling prophecy -- partly because one file-descriptor is generally enough, and partly because of the syntax limits you want to fix. But I think it's very, very important to fix it in a way that doesn't rob the shell of any features it had before, and doesn't build any new walls. ? You do it all the time.

When you do command < filename do you think the shell opens filename as FD 1? No, it becomes some random FD, and the shell just duplicates it over stdin. You're beginning to contradict yourself, you just told me almost nothing cares about other open files. It already does. ...except for special files because they're special.

All this new special syntax is wholly unnecessary. Just make some sort of exec-substitute that returns a file-descriptor number in the form of a string gets you everything you wanted and more, because leaving it as general-purpose lets you use it in ways you didn't originally think of.

I guarantee that if you obscure file descriptors behind anonymous handles, you'll have to kludge a way around that. Maybe not today, maybe not tomorrow, but soon, and for the rest of your life. See man fileno.