During our IT Architecture module, much progress has been made, and we now have our own basic shell.
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.
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.
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.
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.
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.
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.