random memes }

How to get started?

This is simple programming problem. Tune out if this is not your thing.

Started writing a simple cxi (for CGI-like Xml Interchange, perhaps) program as suggested in a prior scripting-oriented article. Pretty straight-forward coding (with some added clever notions that occurred to me later), right up until I got stuck on how to get the child command started.

Commands to be run by cxi fall into two main groups.

Filters are the easier case.

  1. Read environment for HTTP_ACCEPT.
  2. Read the input for headers.
  3. Read the command line for options.
  4. Based on the last found, select the command to run, and set HTTP_ACCEPT for the child process.

Note that the input must be scanned for headers before the child process can be started. Generators are tricky. We cannot read the input for headers (since there is no input), as this would block, and the child process would never get started. We could require pre-knowledge to distinguish generators from filters (a sort of database of command metadata), but this strikes me as inelegant. Traditionally in Unix there is no way to distinguish between commands that are filters and generators. Any given command could be either.

Need a simple convention to mark a generator. I'm inclined to conflate two needs and address with single solution. At the start of a pipeline of cxi commands, you need to establish the desired intermediate data type, as well as indicate that the command is a generator. Since this a usual case, the presence of a command option could indicate both. So a pipeline of cxi commands would look like:

cxi -t xml ps | cxi foo | cxi bar

In the less-usual case, where the initial command is a filter, and addition option could override and force filter-behavior:

cxi -t xml -f ps | cxi foo | cxi bar

In the less-usual case, where the type is indicated in the environment, then another option to indicate the generator:

export HTTP_ACCEPT=text/xml cxi -g ps | cxi foo | cxi bar cxi -g ps | cxi foo | cxi bar

Can't think of anything more elegant, so will go with the above.

As a slightly amusing sidelight - turns out the GNU getopt is too smart for my purposes, and I will have to use an older "dumber" implementation of getopt. The GNU implementation will pick out options anywhere in the command line, and I want it to stop at the first non-option argument.