In this stage of development, we’ve sniffed out a few bugs in our code and implemented two new commands in the prompt.
So I finally implemented the
star commands this week, but it was no solo effort, it was very much a collaborative affai. I genuinely could not have achieved this one without Connor, I was quite literally viewing the problem the wrong way around, and Connor brought a fresh perspective to help break the stagnation of implementing these features.
history command is up first. Very simple functionality in all. For each line executed successfully at the prompt, add it to a file (in this case
.ezsh.history), ensuring the program can perform both read and write operations to this file. Executing
history alone will give you your commands executed successfully in chronological order. Any line of this can be executed once again by appending that line number to an exclamation mark in the form:
star command stores a directory (it must be a directory) to a file (in this case
star alone will give you your list of stars in the order you bookmarked them. Executing lines from this file, however, pops you into that directory you previously starred. The star system ensures that the user can easily glide across the file system with ease. This functionality can be executed by appending the line number of the directory you wish to jump into to an asterisk in the form
So, sounds easy right? Wondering what made it so difficult? Well it’s quite hard to articulate in words, but I’ll give it my best shot.
Essentially, I was tokenizing the input of, let’s say
!4 and dropping the first character. That’s fine. Now I convert it to it’s ascii equivalent and minues 48, to get it as an integer in it’s normal form. This worked fine, absoloutely fine, for numbers 1 to 9 that is. What did I do for the number 10 or 11? Well, they both ended up executing the same command that was at line 1, just as line 20 would execute the command at line 2.
This is where Connor jumped in, he encourgaed my to reverse the string, and multiply each (after ascii conversion - 48) by a power of ten, which would increase based on the number of digits. While it does seem a simple fix, I would have probably never though of it that way, so it’s due to Connor these features exist in the prompt.
I previously stated the issues which would often occur with the Explorer in our previous post. Connor spent a great deal of his time figuring out what was causing this once off occurance.
In the end, it turned out to be a memory allocation issue, though to today we aren’t quite sure why tmux had an influence on such a thing or why it ever caused it to go awry. For now it seems to work well, and we are hoping it’s the last we see of it.
And then it came back ..
In left for two or three days, then after implementing the history command in the prompt side, running both programs in tmux seemed to reawaken the issue from it’s slumber. As I write, it is dormant once again, due to another generous allocation of memory.
Along with this set of fixes to the memery issue the explorer experiences when running inside tmux, Connor has also fixed an issue with the wrapping of long directory names, so they may be readble instead of just disappearing off screen.
With our explorer and prompt working quite well (though currently independant of eachother) in tmux, we felt it was best to add a third pane. This pane serves as a server, relaying commands from the explorer to the prompt and vice-versa.
We are currently debating whether or not this is a socket server, presumably running on port 30000 or something similiar, or if we should used the logged tty’s and pass messages from one tty to the next. This will be something we decide within the next couple of weeks.