bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

some questions about bash internals


From: Bruce Adams
Subject: some questions about bash internals
Date: Wed, 28 Sep 2011 04:34:04 +0100 (BST)

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]