June 15: Sent out a patch to etherboot-developers, with the arithmetic parser. Well, before that I had to actually make the patch, which required some messing around with git. Had an accident which resulted in losing a script I used to test the parser. Anyway, finally managed to send it out.

June 16: I had a look at the POSIX specification for the shell. These points seem of interest to my task:

• Within double quotes, the $ retains its special meaning for variables and for arithmetic expressions, and the \ for escapes
• No escapes are allowed within single quotes

Went through AndyTim's and Stefan's work on quoting. Started coding something up, which I later realised would not work. The thing here is that once the string is expanded, it will not really be possible to find the division between arguments. The current flow is: expand_command → split_args → exec.

June 17: Still confused about how to implement the quoting. Towards evening decided to combine the expand_command and split_args functions. This might make it a little difficult to understand, but let's see how it turns out. Commit: Beware, this is very rough, and I still have to do the cleaning up

June 18: Continued working on the same idea. Worked on the memory leaks, and putting in the quotes for the arithmetic parser, too. Commit: Almost works

June 19: Had a talk with Stefan about the work done so far. He mentioned that a table-based parser might be a good idea, since the expansion code works almost the same. I tried out that approach, first as a stand-alone expansion function. So it's back to valgrind, to test the memory allocation. It does look much better than the previous code, since there is not too much code duplication. Once I tested it, I integrated it into gPXE. Commit: Table-based

June 20: Trying to decide the implementation of if-else branches (next week's task). This is what I've thought of:

if <cond>
     <statements>
else
     <statements>
fi

I will also have a stack of boolean values, representing the evaluated conditions. Each time an if is encountered, the condition is evaluated and pushed on the stack. Similarly, when an else is encountered, the top of stack is negated, and when a fi is found, the top condition is pushed off. Statements should be executed only if the value on the top of the stack is true, or they can change the stack.

June 21: Did some last testing, and sent out my work to Etherboot-developers. Here it is.