[Top][All Lists]
[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.
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- some questions about bash internals,
Bruce Adams <=