One can take this argument to the extreme: say anything that's not part of one of the "standard" commonly-used shells is not a feature of a "shell language". If it wasn't invented at least 15 years ago and implemented as part of something with "sh" in the name, it's no good.

One could also take the broader view: if features are identified that could be of value, find a way to incorporate them while still keeping the shell as conceptually sound as possible.

True, just like you can't stick an array into a command line argument. You can stick a representation of an array into a command line argument, you can stick array elements into separate command line arguments - but not the array itself, as a single element.

Unless you're doing a mathematical operation, for instance.


Shell doesn't use the addition operator for string concatenation, so there you go.

The latter would be great - but as far as I can tell you can't store a null byte in a shell variable - and therefore you can't specify the null byte as $IFS.

Though, again, that could be fixed without revolutionary change: just make it possible to create a variable in the shell whose contents include a zero byte. You wouldn't be able to export it, of course ('cause the zero byte would be taken as a terminator) but it'd still be useful internally as $IFS.

Removing features is sometimes necessary to incorporate new ideas and result in a coherent whole. If every design decision is hobbled by a strict "break nothing that already exists", the process goes nowhere.

Other people might expect lots of things. If they're unwilling to learn a new set of rules, nobody is forcing them to use my shell language, you know? Obviously not everyone is going to think the "improvements" I choose to make are improvements. Different people have different ideas. But progress is not made unless ideas are tested.

That is not what it's doing.

If you don't quote it, it expands the variable's elements to separate arguments on the command where it appears. (If an array element contains $IFS, the shell does not split that argument when the array reference is expanded.)

The bit that's really screwy is if you do this:

Code:

$ b="${A[*]}"
$ echo $b

$b is not an array, and I've explicitly set it to the quoted (that is, delimited) form of A's contents. But in this case 'echo $b' produces the same result as 'echo ${A[*]}' - $b is expanded to positional arguments as if it were an array (even though it's not an array, and was initialized with a quoted string!)

I don't see how that can be anything but a bug...

But as I said - I don't want to leave the impression that I'm taking bugs as evidence that there's something wrong with the fundamental approach. That wouldn't be sensible or fair.

I am taking a closer look. And I already have. I know enough about bash that I can answer the kinds of questions about it that most people don't ask. And sometimes, in answering them, I learn a bit more about Bash's strengths.

On the contrary: you have to bend over backward to translate arrays to strings in a way that preserves their structure. To do it right requires translating the array contents to syntax.

I did, after all, translate the array to a string in exactly the same way as you did. Hence, my argument that arrays don't translate to strings. They are an exception to the common rule in the shell that everything should translate neatly to string form.

That's good, because they don't:

Code:

command < file | command2 | command3

Only the first command of that line gets it.
[/quote]

That isn't the case I'm talking about.

Code:

# open the file in the shell environment
$ exec 7<file
$ cmd1 | cmd2 | cmd3
# Which processes have FD 7 open?  Which ones needed it?

Ugh. This is the problem with no nested quotes.

You had pointed out that when you open a file and immediately redirect it to FD 0 (or whatever) the open() call initially puts it on a different FD, and a dup() call moves it to FD 0 for the context to which the redirection applies.

I pointed out that this has no bearing on anything. Nobody cares what that "intermediate" FD number was, they only care about the final one that applies to their process.

Strict adherence to this rule is the path to madness via Solipism.

So, yeah, I'll make assumptions here and there. That's how language design works, you start with an idea of how things could or should work. It doesn't mean it's always true, and the real proof of whether the idea was any good is in the implementation and how it plays out in actual use.

Sometimes "more options" really does just make the language a mess. Remember how we were talking about Perl a little while ago?

You're scoping the file descriptors and their variables by using subshell syntax. That means you are unavoidably limiting the scope of everything else, too. If you wanted to use this block to read a file and populate a variable, you're out of luck, 'cause that variable binding won't make it outside of the "subshell" block.

You're taking this all-or-nothing kind of position and you haven't justified it. I can remove "exec 7<file" from shell syntax and replace it with improved support for redirecting code blocks (i.e. provide code blocks that aren't loops or subshells) - I don't see how anything of value is lost.

I know it's already valid shell syntax. That's why I'm using it as an example of how things could work. As pre-existing syntax, it's something that you can read and know what it's supposed to be doing. I don't have to explain what it does, 'cause you already know.

Because if file descriptors are "just integers" then the shell can't manage their lifetime. Scoping is a worthwhile feature IMO.