Quote:
Originally Posted by
Corona688
The shell is a more direct interface to the environment and the kernel than a lot of people realize. File numbers in shell are the file descriptor numbers the kernel has actually assigned to this process, nothing more, nothing less.
The same is true of file descriptors in C - but when you call open() to open a file there's no chance of accidentally closing a file you had open - the newly-opened file is assigned to a previously unallocated file descriptor.
So there's that basic problem of syntax when using redirection syntax to open files... That much could be solved pretty easily. (Actually, I guess Bash already has it pretty much licked: "exec {newfd}<filename"... $newfd takes on the newly allocated file descriptor number...)
But why stop there? There's no reason the shell couldn't tie the idea of an "open file" (within the shell) to a specialized, non-exportable variable, which offers the possibility of scoping and reference-counting the file descriptor, closing it when it's unused within the shell process. This would also give us a natural way to express whether the file descriptor should be "exported" to child processes (i.e. whether it's kept open through a fork()/exec()) - if the variable is exported, the child process gets an environment variable with a file descriptor number in it, and that file is open. If it's not, the file descriptor is closed on (or before) exec().
There's no reason numeric redirections couldn't still be made available for those cases where you need to control exactly where an open file ends up for a specific child process. I think that's just not the common case. The common case is that people want to read from or write to files. The bash/zsh syntax that allows opening a file and assigning its descriptor to a variable is a step in the right direction, but I think there's no reason things couldn't be improved further.
Quote:
Environment variables (though not non-exported variables)
I want to point out that exception because it's an important one. Variables implemented in shells are already removed from the reality of the underlying mechanism of environment variables. You've got integer variables, array variables, hash table variables... Shells provide these special cases despite the fact that they don't fit the underlying environment variable mechanism (and, therefore, can't be exported) because they're
useful.
Quote:
Moving away from the model the kernel presents you would make it a more capable language, and a less capable shell.
Well, granted, though with caveats.
Let's suppose, for instance, I actually were proposing a shell design that wouldn't allow for numeric redirection, and that I were running one of the few programs for which that feature is actually useful. (I only know of a few - xterm, screen - can't think of any others...) Then, yes, something of value was lost.
But this doesn't mean that working with raw resources must be the
default means of interacting with the shell - only that it must be available, and that the shell's normal mode of operation shouldn't be
too far removed from this. The raw control should be there when you need it, and
out of the way the rest of the time.