A system block diagram

I tried out LibreDraw, figured on making a block diagram of the join system.  I also did quite a bit of software yesterday, after working my tax form.

But, the point is, the shell.  It knows othing about what is going on, all it does is generate command sequences of the form:

cmd arg1 arg2 ....NULL

all elements of the valid command sequence are encapsulated in an array of Nul pointers and called with:

int Entry(int * argc, void * argv[]);

The argv is, in essence, the program and argc the program counter all kept in shell space.

The cursor manager will partially execute those cursor commands that need management, but otherwise passes the command and control to the grammar specific layers, as in:

// go through the list of attachments

// and pass the command down

while(devices[i].entry) {
if(devices[i].entry(argc,args) == SUCCESS) 
 break;
 }

The the command and control interface has inheritance properties making configuration much more systematic.  Further the subsystem grammars may alter the argv list, and otherwise us them for both inut and output making command and control a full duplex process. And the nice thing, if the new macro capability is not called out then it should default to bash syntax.


Initialize:

I have a simple rule, the first shared object loaded from the shell becomes he executive, and is the only module called by shell.  All load requests are followed by the command sequence: Init, using:  argv[0]="Init"; 
entry(argc,argv);
which is passed down the line to the specific grammar attachment that was loaded loaded.

So the system maximally uses inheritance, informally,  in both command path and run path.  The shell is kept completely in the dark about any of this, just preparing command sequences from the script with no knowledge of their function.  Shell does not even include any headers from any particular subsystem, and could be managing an apple farm for all it cares.

This works because the bash macro grammar and linux argument list standards are well accepted, so shell can just duplicate that functionality in one parse routine.  That exposes the extra functionality in treating the arguments as first class variables without destroying old style functionality..

The added advantage, each command handler needs to break out the argument list anyway, so why not have the macro scripter do it once at the start.

 Code status:

I am slowly updating the files listed on the right side of this blog.  Most of this architecture is in place in the lab, but I hesitate to post all the files as I cannot say I am ready to expose a production beta.  The files on the right will not compile together, at the moment, and should be read as prototype examples of the production beta changes.