You say I may have a lot to learn - I acknowledge the possibility. If I did not have the conviction to test my ideas like this, I would miss an opportunity to find out where my knowledge is lacking.

I've made a lot of progress along these lines already. Things I thought the shell couldn't do, things I thought it wasn't appropriate for - as I learned more about the advanced features of the shell and how they're used in practice I started to understand some of my understanding was wrong.

This is very important from my perspective. If I don't know what the shell currently provides, I can't hope to successfully "improve" upon it. If I change the shell syntax, and lose various features in the process, I have to understand what those features are and how serious the loss is.

Bash's diverse variable substitution syntax is a good example. It tends to strike me as a giant mess. But it's powerful stuff, too. Things like "This variable, unless it's unset in which case this string instead" or "this variable, but trim a bit of text out of it first" - it's good stuff.

You do make a good point here, I think... It may be a good argument against the idea that things I've described can coexist with the more standard shell approach.

If everything's stored as a string, or if you pretend it is, then you can't specialize for different data types. For polymorphism to work you need a clear idea of the "class" that defines the object's behavior. If one sticks to the idea that everything should have an automatic translation back to string, then any time you do an operation on that thing there's the question "did you mean this to be a string operation?"

For instance, a fairly common expectation is that string concatenation (which, of course, is not addition) should use the addition operator. In Perl this wouldn't work, because that would create an ambiguity. "1" + "2" = "3" and not "12" - so they have a separate operator instead.

You see this a lot in bash as well. "Is that numeric comparison or lexicographical string comparison?" I kind of hate that, honestly.

I think there will be other types of "special" variable. I can't give each one its own special character...

Pretty much that's what I'm going for, yeah. A totally new shell, but with familiar elements of Bourne-derived shells in the syntax and operation.

Arithmetic is actually a good example IMO. I feel like the shell should be an environment where that kind of operation comes naturally - it should be easier to express in the shell syntax, I think.

I don't think I've described anything that affects stdin/stdout...

Didn't they get rid of the argument limit? (In Linux, anyway...?) And did it even apply to builtin echo?

What I've described as "special file handle objects" - I mostly use that phrase to tag places where I'm talking about some representation of an open file that's not how things currently operate in the shell. I have, in a few places, considered the possibility that these objects could coexist with the current mechanism for opening files (as in "exec 3<filename" or "exec {f}<filename" for the current mechanism, something else for this "special" crap) but if I'm not going for Bourne compatibility I think there's no point.

It's the difference between having "open this file on this specific descriptor table index, leave it open and pass it on to all child processes until I tell you otherwise" and "open this thing, I don't care where, close it when I'm not using it any more and pass it on only when I say so". I think the latter makes a lot more sense.

Yeeg, there's an awkward distinction...

Code:

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

That is just screwy. (Bash 4 - I don't know what you're using...)

I mean, I get the distinction in the first two commands, even appreciate it: without quotes, ${A[*]} expands each array element to a positional argument, preserving the distinction between neighboring elements - while if you quote it, it's applying $IFS. But what about $x? I set it equal to the quoted version of the contents of A but it preserved that delimitation, as if $x were an array and as if I hadn't included those quotes...

(Obviously when I find things that I think are wrong with bash, that doesn't undermine the merits of bash's basic approach - I don't mean it that way... Just... this seems very inconsistent!)

Consider this:

Code:

# $IFS is still ","
$ A[1]="4,5"
$ echo "${A[*]}"
1,4,5,3

You have lost information in the translation... Hence, I think it's inappropriate to treat arrays as string-equivalent.

I'm not saying redirection to other file descriptors shouldn't be provided:
In fact, my personal feeling is quite the opposite. I believe this feature is essential.

However, it's not the common case that someone will need to open a file on a specific FD and have all child processes inherit that file on that specific numeric FD. As such, I think it's reasonable to fit the syntax to what I believe is the more common case of opening a file: within the shell, you don't care what numeric FD it winds up on. It's only when you launch a child process that uses that numeric FD - and most child processes won't.

What of them?

I actually used this in several examples already... (Well, /dev/fd/ - but it's the same thing)

Let's be clear here: what feature?

Getting rid of numeric redirection?

Code:

cmd 4< file

No. This is valuable.

Getting rid of the traditional mechanism for opening files in the shell, in which the user explicitly selects a numeric FD?

Code:

exec 4<file
cmd --do-something-with-fd=4

Maybe. I know of two programs that operate like this. As such I think this kind of blanket redirection doesn't make a lot of sense. At the very least it shouldn't be the mechanism for opening files in the shell.

Give me a little credit here. I know how open(), dup(), etc. work. I've read APUE. Best $70 I ever spent. And yes, I actually do need to read it again. (The first couple times through I had trouble understanding controlling terminals and job control... I think I got it eventually but I'm getting rusty on the details)

But the relevant point is that when the user runs cmd < filename they don't care what that call to open() returned. They don't need to. They never need to provide or obtain the answer to that question. All they care about is that the file is open for reading, "cmd" sees it as FD 0, and the file is closed when the job is done.

Poor choice of words, perhaps. I was inviting you to think about how frequent that usage is (as in "measure frequency of this occurrence" rather than "boy, is that occurrence frequent!"), with the suggestion that it isn't common. Seriously, do you do that a lot? Say "open this file on decriptor 7" and then actually use descriptor 7 in a bunch of programs, as opposed to redirecting the file to some other FD?

What are you getting at here? I don't get it. I read it and it just looks like you're being rude, giving me a hard time for using the word "special" or something. I don't know if that's your intent.

It doesn't get me scoped file handles, or control over which child processes inherit that open file descriptor, which is kind of where this whole thing started.

As for fileno():
Within the shell it wouldn't normally be important where an open file resides. The use case would be to dup the file descriptor to some other number via redirection syntax:

Code:

# $fh is some "file handle" - a managed open file descriptor.
# User doesn't generally care what its number is, and its behavior in substitutions is not entirely straightforward.
$ read <& $fh
# Dup it to FD 0 to use it with read
$ some-proc --using-fd=7 7<& $fh
# Need it on another FD?  No problem...

Mostly there's no point in knowing where it is as long as you can control where it's going to be.

But there's no reason a feature couldn't be included to determine where the file is. There's not a lot of value to that (debugging the shell would be one possibility, I guess?) but it's doable.