It’s post exam season in DCU, and despite how hectic that 10 day period was, we’ve touched based quite a bit in relation to the project. We made sure that over the Christmas period to carry out some research into various libraries, utilities and testing frameworks we could make use of when developing ezsh. This prologned period of research and upskilling has indeed proved very important in our initial development this past week, which itself consisted of around nine hours of video calls.
It’s post exam season, and we’ve already implemented a testing pipeline and some rudimentary functionality.
We’ve decided to make use of the C unit testing framework cu. cu is an incredibly simple and lightweight framework for handling automated tests in C. The framework provides a simple interface for defining unit tests using macros. Each test suite runs in a separate process - test suites does not influence each other and any failure (such as segfault) does not break up the whole test. CU also provides script for regression tests based on output of test suites. We are really happy with this as a framework, it’s exactly what we need and easy to extended. In general we are trying to work in accordance with Test Driven Development as best we can, this is because we acknowledge the cast number of rabbit holes we can go down in building this project, so we hope adopting this methodology allows us to retain focus on the specification we have set out for ourselves.
We have also set up CI on Gitlab for the project, you can view the .gitlab-ci.yml here. I myself have never used the Gitlab CI, I’m much more used to layout of Travis CI’s YAML files hence why the first ten attempts failed. At the moment we only have one job,
prompt, in which we test certain aspects of the prompt such as it;s abilitiy to tokenize input and colorize output.
We have talked at great length about how the server (to relay info from one pane to another) should operate. Initially it was to be a socket server, running on port 22000 on the localhost. This seems to have been abandoned for a different approach, simply relaying information from one TTY to another. This means that on start up we will have to track the TTY of each pane so as passing information can be made easy. We aren’t sure how scalable this is, nor are we sure at this moment if it needs to scale out beyond this point. For now, this is or preferred method of passing information.
The prompt has seen much work on it over the past few week in particular. At it’s current stage it can read input, tokenize it, and execute it. Changing directory by means of forking a process ID has also been implemented as a built-in command. We still have a few bits to work, including signal handling and autocompletion. A goal of ezsh has always been , from its inception, to be a user-friendly shell, so the colour scheme and presentation of the prompt has always been in the forefront of our minds. In it’s current state, we are making use of colours such as magenta, cyan and green, and the prompt is explicitly clear as to where the user is in the file system. Below you can see the current implementation of the prompt:
This is one section that is only beginnning to receive some work in the past few days. We hope to have it adopt similar schemes from the prompt and for our v0.1.0 we aren’t working towards key bindings or anything too, we are aiming for a simple navigation system which allow the opening and editing of files.
Over the next few days we will have a more detailed analysis on how the multiplexer will work. As it needs to manage a session upon start up with certain programs (whilst also logging TTY’s) we are looking to implement our own stripped down version of tmuxinator. Ideally, this will be a simple shell script in or around 50-60 lines.
In the past few weeks we’ve acheived a lot in regards to setting up testing pipelines, and having rudimentary functionality with the prompt. Over the next week or two we hope to implement botht the explorer and tmuxinator clone, along with some further prompt functionality.