During our IT Architecture module, much progress has been made, and we now have our own basic shell.

Our Workflow 

Progress had been slower than anticipated due to our single module IT Architecture, but that doesn’t mean progress wasn’t achieved. Trying to balance our time between the development process and the work for this module did have an impact, it just wasn’t a worst case scenario kind of impact.

Moving from this point onwards, we have much more time to implement the feature set we established in our functional specification.

Splitting The Terminal 

The splitting of the terminal was achieved through the use of a well crafted shell script, which can be seen here. This leverages tmux to create panes and split up the user’s terminal so separate programs may run simultaneously, with messaging passing occuring between their respective TTY’s. TTY’s are logged to a hidden file, .ezsh.tty, so this may be done at a later stage.

The script itself reads from a hidden configuration file, .ezsh.conf, which describes the number of panes to create, and what programs should execute in each respective pane. This file also adjusts the sizes of panes and will be configurable to the user.

There will need to be som updates to this script in time, as I highly doubt this is the final version. If it is, it’s a miracle.

Building the Explorer 

In the time since our last post, Connor has put together a rudimentary file explorer using the ncurses library. The explorer at this time has the ability to be able to display all the current working directory contents, swap between files and directories inside that directory, and be able to change the current working directory by using the Enter key. In regards to navigation, it’s going pretty strong. There has been an issue, however.

So when the explorer is run as a regular executable file, it runs fine. When you execute the file inside a tmux pane, an odd issue occurs where after the first chaning of directory, the explorer spits out a series of random characters. This issue seems to only occur once, as after the initial slew of characters, it works fine. Connor is currently looking into this issue, and we hope to resolve it in the coming week or so.

Upgrades To The Prompt 

I myself had a fair level of success with the prompt during the final week of January. Once I had finally set up the CI on our Gitlab instance, I turned to implementing autocomplete through the use of the GNU readline utility. This offers a simple, BASH-esque autocompletion with the use of the Tab key, which is bound to the action of autocompletion itself.

During this week I implemented signal handling from ctrl-C. This was an high priority issue at the time as ctrl-C is often used at the prompt, and in all other good shells it doesn’t cause the shell to abruptly stop. Catching ctrl-C proved harder than expected, as I made use of the signal.h header. This, however, has in turn led to some rather interesting issues. For example, if I type in vim and follow it by a ctrl-C, the prompt jumps to the next fine. Great stuff, this is the expected outcome. Immediately after this sequence of actiosn however, I execute the command ls, and out of nowhere, vim opens a new file called ‘ls’. It seems to be that the buffer at the prompt isn’t clearing, so this will have to be fixed in the coming weeks.

Finally, a final fix I made during this period was to the change directory functionality of the shell. Previously, executing cd with no following arguments would result in an error. This has been amended to bring the user to their respective home directory.

More Testing 

In regards to the prompt and the explorer, they both now have tests, where as previously, the explorer didn’t have any, due to the fact it wasn’t working.

The prompts execute functionality is now being tested more rigorously and the explorer’s traversal functionality has had a fresh test suite introduced also. Moving forward we hope to scale out our test suites.

Installing Dependencies 

Finally, I put together a small shell script called requirements. When run by the user, it installs all libraries required by ezsh. The existence of this script ensures that user’s will have the same set of libraries as we have during development so they may run the shell.

You can view this shell script here.