I'm actually working on that... My viewpoint is that sh is semantically a nice and useful language, but it has horrible syntax and bad/old implementations (I've been looking at bash, dash, mksh, and to some degree zsh).
I'm polishing up a very complete shell parser and a less complete interpreter in 10,000 lines of Python. Most of the problem is parsing -- executing is easy once you've done that. It's actually closer to the bash superset than POSIX sh, so it will be able to run many real programs.
I started with 3,000 lines of C++, but felt like I would never finish with that iteration speed. Now that I know the language inside and out, I can port it back to C++. There are 3,000 lines of tests in a custom test framework which can run against any sh implementation.
I have a few blog posts planned ... if anyone is interested in a link send me an e-mail with subject line "new shell: me@example.com" (address in profile)
I discovered a lot of interesting things about the language and its implementations, like:
- It's actually 4 languages/parsers interleaved, which I call: command, word, arithmetic, boolean (boolean is [[ which is the "compile time" version of [). Then there are some tiny sublanguages like glob and X{a,b}Y brace expansion.
- It can be parsed preetty completely up front, in one pass. Current implementations tend to defer parsing of the stuff inside ${a} $( ) and $(( )) etc. for subsequent passes. They interleave parsing and execution.
But there's only one situation where parsing really depends on execution -- indexing of assoc arrays vs arrays (${a[X] vs ${A[X]). This is in contrast to Make and Perl, which both interleave parsing and execution.
- places where the POSIX spec is stricter than implementations. All implementations accept 'echo 1 >out.txt 2 3' in addition to 'echo 1 2 3 >out.txt', but the POSIX grammar doesn't allow this.
- places where the POSIX grammar is more lenient than bash. The POSIX grammar allows functions defs with a single statement, without {}, like:
$ dash -c 'f() echo hi; f'
hi
But bash doesn't allow this.
There are a whole bunch of other things but I will save them for the forthcoming blog.
I'm polishing up a very complete shell parser and a less complete interpreter in 10,000 lines of Python. Most of the problem is parsing -- executing is easy once you've done that. It's actually closer to the bash superset than POSIX sh, so it will be able to run many real programs.
I started with 3,000 lines of C++, but felt like I would never finish with that iteration speed. Now that I know the language inside and out, I can port it back to C++. There are 3,000 lines of tests in a custom test framework which can run against any sh implementation.
I have a few blog posts planned ... if anyone is interested in a link send me an e-mail with subject line "new shell: me@example.com" (address in profile)
I discovered a lot of interesting things about the language and its implementations, like:
- It's actually 4 languages/parsers interleaved, which I call: command, word, arithmetic, boolean (boolean is [[ which is the "compile time" version of [). Then there are some tiny sublanguages like glob and X{a,b}Y brace expansion.
- It can be parsed preetty completely up front, in one pass. Current implementations tend to defer parsing of the stuff inside ${a} $( ) and $(( )) etc. for subsequent passes. They interleave parsing and execution.
But there's only one situation where parsing really depends on execution -- indexing of assoc arrays vs arrays (${a[X] vs ${A[X]). This is in contrast to Make and Perl, which both interleave parsing and execution.
- places where the POSIX spec is stricter than implementations. All implementations accept 'echo 1 >out.txt 2 3' in addition to 'echo 1 2 3 >out.txt', but the POSIX grammar doesn't allow this.
- places where the POSIX grammar is more lenient than bash. The POSIX grammar allows functions defs with a single statement, without {}, like:
But bash doesn't allow this.There are a whole bunch of other things but I will save them for the forthcoming blog.