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?
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.