Ken Irving - 2008-04-06

Currently thinobjects must be ``enabled'' to function as objects through the use of the tob ``enabler'', e.g.:

    $ tob myob.doit args...

The tob script parses the object and method from its first argument, and so on.  This works, but is a nuisance.  A suggestion from someone that it would be better to be able to have native shell support for objects got me to thinking...

In the bash shell, if a command is entered like:

    $ myob.doit args...

the shell will respond with "command not found", since myob.doit is not found anywhere on the user's PATH nor is a builtin.  The obvious thought, then, is to try to hook onto that behavior and re-execute the command using the (now implicit) tob handler/enabler.

It turns out this is *almost* already possible, at least under debian's bash.  A patch was submitted to upstream bash for such a handler, and  while it has not been accepted into the bash project itself, it was accepted in the debian bash package, so is enabled by default.  The mechanism is simple: a command_not_found_handle() bash function will be called in the event, if the function is defined.  Unfortunately, only the command name itself is passed or otherwise made available to the function (as far as I've found).

Currently, then, given a command_not_found_handle() like:

    tob $@ || exit 127

the above command would become:

    $ tob myob.doit

with the args... omitted.  This is unfortunate, and so at this stage is not sufficient to the task.  I've tried to find ways to re-attach the arg list, but haven't been able to find it in /proc/$pid/cmdline or elsewhere, and so am stymied for now in the effort.

Looking at the patch for this feature in the debian package source, my impression is that the author may have intended, or begun, to provide support for the arguments, but didn't complete the job for whatever reason.  Maybe people see some advantage, perhaps safety (?) in only having the command name available; one use in another debian/ubuntu package is to do an automatic lookup of the erroneous command in the package archive, and offer to install it.

If my C-foo was better I could probably whip up a simple patch to do the job.  The command_not_found_handle patch defines a couple of variables, a pointer to the command, *c (I think; could be different...), and another *v which is not actually used.  My guess is that this was intended for the ARGV list.  So a fix would be to finish the job by assigning ARGV to that *v variable, and that's where I've stalled out on the job.

Various approaches could be taken.  Maybe simplest would be to coerce the args into some bash variable, which could then be used or ignored in the event handler.  Another would be to explicitly pass those args to the handler in its arg list.

I think someone familiar with C enough to understand declarations and such could easily do the job, but so far I've just gotten lost in the pointers and pointers to pointers, lists, environment variables, and so on.  There are imported functions available to set environment variables as scalar or array values, but it's for now just out of my reach.

So until someone steps up and pushes on this a bit, we're stuck with having to precede thinobject commands with tob.  The prospect of native
support is intriguing, particular since it seems to be pretty unambiguous, given that few (if any) actual commands have an embedded dot/period in them.  I think there's little danger of running afoul, colliding with the wrong command or accidentally invoking object.method.  To me, at least, this seems like potentially a very clean approach, and I hope to get there eventually.