Enhanced options for the command interpreter

[stevesims]

The command interpreter itself (the mos_exec function) has fairly sophisticated behaviour when processing a command. It essentially goes through the following steps:

1. check if command is empty or a comment (comments are lines starting with # or | )
2. strip/skip any leading space or * characters
3. check if the command is an alias
   • this step will be bypassed if the command begins with a %
   • if it is an alias, the alias is resolved, substituting in arguments
   • it will then return the result of a new call to mos_exec passing in the resolved alias
   • there is a call depth check that happens which prevents an infinite loop of aliases - this is a hard-coded depth of 10 calls
4. check if this is an inbuilt command
   • if so then if the command wants system variables automatically expanded then do that
   • execute that command, returning the result
5. otherwise attempt to match the command to a binary file and run that, returning the result

The mos_oscli API calls mos_exec passing a flag which changes the filename search. Instead of using the run: prefix, which will use the path defined in the Run$Path variable, it uses the moslet: prefix, ensuring that only moslets will be found/run.

It should be noted here that if the command to be interpreted contains a path prefix (which can be run: or moslet: or any other path prefix) then that path will always be used to search for the file to run, and the prefixing described above will not happen.

NB it is intended to enhance step 5 to support matching any file that has a run type set for it, see #78. This would let you type in the name of any file with a known run type and have that file run.

The command interpreter currently has no way to prevent step 5 from running. This could be a useful addition.

From an API point of view, mos_oscli only accepts a pointer to a buffer containing a command string. Adding flags to the existing API call would be incompatible, as existing code may have set the flags register to be anything.

One possibility to allow further customisation of how commands are interpreted could be to add flags to the do command. The main purpose of this command is to allow for the execution of a command that has been defined inside a system variable. An example would be do <Var$Name> extra args - attempting this without the do won't be recognised.

The do command handler is a simple call to the mos_exec function. As it has no way of detecting it was called from the mos_oscli API, the search path used will always be the full run path (as defined in the Run$Path variable). This is arguably desirable behaviour, even though it carries some significant risks. It's a definite "use with care" feature.

There are therefore potentially two useful flags to add to the do command handler. One to completely disable the automatic "run file" behaviour, and another to restrict the "run file" behaviour to running moslets only.

It should be noted that files could still be run using a the RunBin or RunFile command.