One thing I forgot to mention is that I've been working on a new layout for my website, which is mostly completed. Still need to do some work on some of the styling, but I'm mostly happy with the layout of the site. It's not exactly an original design, but it's a significant improvement on the half style I used to have.

The next step is to improve the style so I don't have to repeat the style and html on every page and I'm hoping to do it without php. I have some cunning plans involving python and xslt, but we'll see how that goes.

Also, after several months, I fixed my blog comments to not give a 500 Server Error, so people can now freely spam my comments. Turns out that the comments plugin didn't have write permission to the comments directory, but pyblosxom kindly didn't prove any hints beyond "Premature end of script headers". Cheers.

Yesterday I posted about some bad shell code I had found and posted an improved version. Part of the reason for posting it was that I hoping someone could point out any errors in the version I posted. Fortunately Neil Moore emailed me some improvements.

1. If the script returns more than one line they will be removed by the $(...) expansion when it is split into words. The solution there is to surround it in double quotes.
2. The next problem Neil pointed out was that $@ should be surrounded by quotes in pretty much every case, otherwise parameters with spaces in will get split into separate parameters.
3. The final problem is that if the script includes a return statement, it will stop the inner most function or sourced script, but not during eval.The solution is to enclose it in a function:

   
   dummy() { eval "$(perl "$CONF_DIR/project.pl" "$@")"; } dummy "$@"
   

Since making the post, I discovered that Solaris' /bin/sh doesn't like $(...), so it's probably better to use backticks instead if you want to be portable. As I know the output from the script I'm not worried about return statements, so I've ended up with:

eval "`perl "$CONF_DIR/project.pl" "$@"`"