It looks like this probably qualifies as a Show HN as well, if you can edit the title.
What are your future plans for the project? Are you using it regularly?
I don't believe so. We changed the name to "Dart" from "Dash" because the lawyers did a trademark search and felt the former was a safer bet.
This document is much more appealing to me than the project's README. Since people often browse just the README when visiting a repository on GitHub, I wonder if you would be better off getting some of the language from sections 1 and 2 into the top of your README. The current README Overview just didn't do it for me. As soon as I saw the first two sections of the user manual, I was more interested because it showed what problem you were solving and how.
> Warning - This manual may reflect a future state of szl.
Got a chuckle out of me.
I think it mainly has to do with the fact that bash has no references and garbage collection. When you create an array like [1, 2, [a, b]] in Python/Ruby/Perl, you are introducing the concept of references, as well introducing hte potential for reference cycles.
In contrast, an array in bash is just a value, and it took me awhile to figure out how to even copy it. None of these work:
a=('x y' z)
b=${a}
b=${a[*]}
b=${a[@]}
b="${a[*]}"
b="${a[@]}"
b=( ${a} )
b=( ${a[*]} )
b=( ${a[@]} )
b=( "${a}" )
b=( "${a[*]}" )
b=( "${a[@]}" )
In sh, each function has a local array, and you use that array with "$@". And typically you can get along with only that array. Not so bad.
my_b() {
somefunc foo "$@" bar
}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
There are a whole bunch of other things but I will save them for the forthcoming blog.