There's still a contradiction in that. If you want these features, don't use a shell language. You can't stick a polymorphic object into a commandline argument. There's no ambiguity. The answer is always, always "yes". Remember that this is a shell. You have to put these things into commandline programs. Strings are the only things that make sense. I haven't seriously used a language that did that since I stopped writing in BASIC. Well, nobody forced you to use a shell language. And again you've missed the point. Every time you decide something deserves to be a special case and give it its own, special types and syntax you create more and more walls between your builtins' syntax and what you allow the programmer to do. Don't specialize, generalize. Yeah, just everything else. More and more special magic things. No. Who says you're running "echo"? Feeding them all into echo like that would have side-effects on the contents of the string.

Besides, imagine what you'd be able to do by fiddling IFS. You could make it produce all the strings seperated by commas, or by NULLs, without needing an external program. The point is to not deny yourself features. Just because you don't need it this instant doesn't mean you're not going to need it the instant you make it opaque. They've tried many times. stdio tried to wall it all off behind an opaque pointer because you don't "need" anything else, and ended up needing fdopen() and fileno() because sometimes, you actually, genuinely need it. They tried hiding it all behind C++ iostreams and people wouldn't have it, resulting in a stew of nonstandard iostream extensions allowing you to get or at least set the file number for one of them. Stop deciding what programmers "really need" and just hand out the stupid fileno. All you have to do is shove it in a string variable and it's as tidy as you could want. False dilemma. You don't have to have it 100% your way to get everything you want. Just an exec-like command that puts a file descriptor number in a string does what you want. And a shell builtin to set the kernel's close-on-exec ioctl gives you the rest. You could even have that as a flag for opening it. But as the default? Remember that people other than you might have to program in this language, and might expect "open the file" to just open the file without cleaning their laundry too. It makes perfect sense when you think about it -- IFS is the character a shell splits strings on! How do you stop a string from being split? Quote it, of course. There's nothing inconsistent about it, it's always substituting in the commas -- but if you don't quote it, it splits on the commas just like it'd usually split on spaces! This is what IFS does -- it's the characters the shell splits on, not just in arrays, but most substitution. Don't jump to conclusions, take a closer look. Only because you intentionally threw it away. That's quite all right, but if you don't want to program in a shell language, you don't have to program in a shell language. It's all about strings and splitting strings and can't really be anything else because that's the only thing you can put in a commandline. That's good, because they don't:

Code:

command < file | command2 | command3

Only the first command of that line gets it. You have exceedingly fine control over it already. You always care what FD it winds up on: Generally zero. You know what they say about assumptions: They make an ass of you and me.

How users want to use files is a question of programming style. Don't give them less options, give them more!


Yes it can.

Code:

(
        open FOUT>filename
        open FIN<filename
        # How about this syntax, or something like it, for an implied close-on-exec?
        open -FD<filename
        
        do_stuff_with <$FIN >$FOUT
)
# How about a new kind of bracket that scopes files but not variables?

${
        open -FD<filename
        stuff <$FD
$}

The point is, you don't need to throw away this feature. You can get what you want without throwing it away and adding 9 new variable types plus operator overloading instead. That you don't find it personally useful doesn't mean it's useless. This kind of "blanket redirection" is the foundation of how files, pipes, redirection, and terminals all behave. If you want to close that all off, make these "special cases" all part of your language instead of part of the environment, fine, but that's not a shell. ...but I'm not sure you understand why.
So what? We've been asked on these forums before, how to do exactly that. Occasionally. If you removed that feature from the shell I'd have to hack it back in since there's things that can't be done without it. Think back to how I started my post, explaining about a language crammed with special cases that had to be worked around in very awkward ways. The more special cases you add, the more awkward corners you add. You can get that kind of control without completely obliterating the model we have. It's not "usually" relevant in a C program either, but it's quite important enough. I'd like to point out, yet again, that this is already valid shell syntax. You don't need to add new variable types to make this works. Set the string fh to a valid file descriptor number, use a builtin to set close-on-exec, and you've got it. My question is: Why make it a new special type of variable in the first place? File descriptors are actually, really, genuinely integers. You're actually making it harder on yourself intentionally hiding the integer from view instead of just storing it in a variable where anything, shell included, can use it.