Fundamentally it is more like tcl (function chaining) than like bash (process chaining), where process pipelining is the central operation, and where functions and programs are equivalent. In that sense, it has mostly the advantages but also the inconveniences of tcl, javascript and similar non-shell scripting languages. My opinion is that they have quite missed the ball in bash on non-nestable arrays when they introduced them quite recently, but besides that, bash is still pretty much my favourite tool.
Yes, in writing my bash parser/interpreter (see below) I explored the non-nested arrays and assoc arrays issue.
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:
I think someone needs to write bash the good parts. It is easy to get into a mess because bash wasn't really designed with modular programming in mind. I very often fall back to using files and exported environment variables to pass information between scripts which isn't that great. I still prefer it to ruby or python or some other scripting language because as you said pipes are very convenient.
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.
Sure, but variations are there so the reproducible builds are more robust and can be done natively. It doesn't mean that you can't reproduce these packages, just stick to the standard build paths, filesystems, etc...
> Fred Brooks concludes that no software product should be designed by more than two people.
That really depends on the architecture of the software. There are thousands of people creating and maintaining device drivers for the linux kernel. The idea that only two people could do that simultaneously, is a bit far fetched when the architecture actually makes sense.
But then again, most commercial software does not have that kind of extensible architecture. Therefore, it is probably true that a commercial software team will never really scale.
It's been a while since I read the Mythical Man Month, but as I recall his answer to your point is to look at things through the perspective of systems and subsystems. While Linus is responsible for the overall Linux kernel/system, someone else may be responsible for the X subsystem in the Linux kernel. Which, from what I'm aware, is an accurate representation of how Linux is developed in practice.
