Tagged: scripting

Hello Lua

Lua logoBack in the day, when I used to play World of Warcraft (shame on me), I noticed they use something called Lua to let players extend their user interface with various addons and tweaks. It worked very good. There are literally thousands of available addons for World of Warcraft. I quit the game about 2 years ago and I never got to look further into Lua, until now.

As it turns out, Lua is quite popular among game developers as an extension scripting language due to it’s C API. Common practice is to implement the engine and some basic game features in C++ and then script all the content in lua. That way it’s easier to tweak the game, because it’s not hard-coded and compiled. As the official website says:

Lua combines simple procedural syntax with powerful data description constructs based on associative arrays and extensible semantics. Lua is dynamically typed, runs by interpreting bytecode for a register-based virtual machine, and has automatic memory management with incremental garbage collection, making it ideal for configuration, scripting, and rapid prototyping.

Sounds pretty neat. And on top of that, lua is open-source. It’s distributed under the MIT license!


Getopt in Bash

There are two different ways of parsing command line arguments while using getopt(3). There is an utility called getopt (man 1 getopt). This utility is available in all shells. Then in bash, there is another built-in tool for parsing arguments called getopts (it’s a built-in, so it doesn’t have it’s own man-page — try help getopts).


Here’s an example script that demonstrates the usage of getopt:


# Execute getopt
ARGS=`getopt -o "123:" -l "one,two,three:" \
      -n "getopt.sh" -- "$@"`

#Bad arguments
if [ $? -ne 0 ];
  exit 1

# A little magic
eval set -- "$ARGS"

# Now go through all the options
while true;
  case "$1" in
      echo "Uno"

      echo "Dos"

      echo "Tres"

      # We need to take the option argument
      if [ -n "$2" ];
        echo "Argument: $2"
      shift 2;;


At first, the getopt utility is called with desired parameters (see man getopt for detailed description of all the options). If it returns anything else than 0, something was wrong and we’ll end the script. There is no error message necessary, because the getopt itself will inform user about what went wrong.

After that, there’s a little magic line with eval and set. It’s there to preserve whitespaces inside options arguments. Detailed description of this technique is here.

All options are evaluated and appropriate actions take place in the while loop at the end of the script.


Here’s an example script that demonstrates the usage of getopts:


while getopts "123:" OPTION
  case $OPTION in
    1)  echo "Uno";;
    2)  echo "Dos";;
    3)  echo "Tres: $OPTARG";;

    # Unknown option. No need for an error, getopts informs
    # the user itself.
    \?) exit 1;;

As you can see, the bash built-in version is easier to use, but it can’t handle long options like --option.


Which one you should use? Well, it’s up to you, what you need. If you’re looking for compatibility of your script among more shells than just bash or want to have long options, you’ll need to use the getopt utility. If not, I’d go for the getopts built-in, which I personally consider more user-friendly.


If you liked this post, make sure you subscribe to receive notifications of new content by email or RSS feed.
Alternatively, feel free to follow me on Twitter or Google+.