Re: Preparing the reduced bootstrap tarballs

[Timothy Sample]

Hi Jan,

Jan Nieuwenhuizen <address@hidden> writes:

> Timothy Sample writes:
>
>> I wanted to let you know that I’ve been doing more work on the little
>> Shell backend that we were talking about earlier.  It’s kind of like the
>> worse-is-better version of Gash: it is certainly not as nice, but the
>> development pace is much faster.  I did take a look at just working on
>> Gash directly, but it looked like it was going to be a lot slower.
>
> Oh, that's great news!  We have been making good progress on Gash.  The
> parser has been completely revamped.  The next target is to add a
> transformation that should result in a eval'able shelly Guile script,
> ideally something that you'd want to write by hand.

That’s what I like best about Gash.  My “shelly” code is a mess and no
one should write it by hand!  :)

> To achieve that will take some time.  It would be nice if we could work
> together shaping this shelly script language .

I agree, but I am hesitant to worry about this now.  The more I work on
Geesh the more I realize that building a shell is a big project.  I’ve
consistently been moving from worrying about making things work nicely
to just making them work.  I hope that once the basic features are in
place it will be a lot more fun to improve things gradually.  Does that
make sense?

> If Gash and Geesh would produce (after transformation) the same shelly
> script language, we can also share the backend implementation, WDYT?

I’m a little bit confused about this.  After we exchanged notes last
time, I thought we were going to share front-ends.  Now it seems you’ve
doubled-down on Gash’s PEG parser and want to share back-ends.  Why the
change in plans?  It makes more sense to me to share front-ends because
the parser in Geesh is quite complete.  Also, you already wrote some
code to transform its output into a Gash script.

>> So, keeping in mind that software estimates are very unreliable, I would
>> say that I might have a workable interpreter in the next week or two.
>> There are three big features missing: globbing, asynchronous commands,
>> and arithmetic substitutions.  I am almost finished globbing,
>> asynchronous commands should be pretty easy, and I plan to leave
>> arithmetic substitutions on the road-map for as long as possible (it’s a
>> little bit boring).
>
> Hehe.  I had a look and you did make lots of progress!

So have you!  It’s pretty funny that we both picked up working on this
at about the same time.  In hindsight, I should have contacted you
before diving in again in order to minimize duplicated work.  On the
other hand, it seems you’re guilty of the same thing!  Oh well.  ;)

I‘m not too worried about it, and I’m having fun.  I hope you are too.

>> After I get those first two features working, I am going to start
>> testing running build scripts for Bash.  I will contact you then in case
>> you have any new advice on which scripts are important or anything else.
>
> Great,
> Keep up the good work!

I skipped asynchronous commands and implemented a bunch of built-ins
instead.  Now Geesh will run most of Bash’s configure script.  It runs
until it tries to write “config.sub” which it writes incorrectly due to
an unset variable (ironically, it seems to be the “$SHELL” variable).
That means it chews through over 17,000 lines of configure script!  It
does this very s-l-o-w-l-y, but it’s exciting all the same.


-- Tim