Hi, I have some questions about the internals of bash.
I have been looking at porting (a copy of) the bash source tree to a more modern dialect of C primarily as a coding exercise and also to allow some comparisons to be made. This a slightly different take on the write a bash clone in C++ or Java exercise. (I realise that dash might be a more suitable starting point as it is significantly simpler). If it were written in a dialect of C that could be compiled by a C++ compiler some comparisons of C++ vs C (on a useful and mature project) could be made. For example, the often made claim that C code compiled as C++ is significantly slower could be tested. (personally, I am not convinced it is true). The GNU coding standards (http://www.gnu.org/prep/standards/standards.html#Standard-C) include support for pre-ANSI C. Are there any users that actually need to compile new releases of bash on a pre-ANSI compiler? Does anyone out there still using a pre-ANSI C compiler at all? (I tried using protoize experimentally with no luck. It is either broken or I don't grok it) The GIT repository (at savannah) seems to record only snapshots of each historical release of bash. Does the original source history still exist somewhere? The CVS directory is empty (presumably following the move to git whenever that was). I would be interested in looking at some of the deltas made showing how bash has evolved. I'm assuming it was in CVS before it was in git and in RCS before that and uncontrolled even earlier. Is there any further documentation on how bash is architected? I have read: http://www.aosabook.org/en/bash.html which provides an overview. It is less obvious how and why the files and large components are actually arranged. For example I know readline is available as a separate package but it is not clear how the source trees are kept in sync. Does the bash project 'own' readline? On savannash readline seems to be maintained in CVS while bash is in git. Though I cannot seem to view the source tree for the readline project on savanah. What bits constitute GNU lib or any other libraries is not obvious in the bash source tree. Why would bash need to include its own version of malloc for example? I would assume a working C standard library to be a pre-requisite or at worst provided by autoconf magic. Perhaps it is that autoconf magic that I am looking at, if so the boundary between it and the bash source is blurry. Coming from a 1 header 1 source file background the mapping of the 240 .c files onto the 111 .h files is not always clear to me, though 1 header 1 source file seems to be mostly adhered to. The tracker at savannah lists only 11 items. My conclusion is there must be another tracker elsewhere, or that the mailing list is used instead. The latter seems probable given a brief browse of the list archive. Finally, bash is very stable and mature but are there any architectural issues that should/could be usefully worked on? as opposed to more academic exercises like those originally mentioned. Regards, Bruce.
