int WhileCommand(int *argc,void * args[]) {
int count = atoi( (char *) args[1]);
*argc += 2;
while(count--)
ExecCommand(argc,args);
}
Here is my original shell c script::
int n;
while(n) {
execute some code
}
Then the parser will generate a cmd sequence of the proper form as in the linux cmd argument format as an object format:
cmd ar1 arg2 ...;
The while command object formats, not all implemented would be:
where count // Use immediate integer
where -var varname // take the count from the symbol table
where -local argindex // take the count from the local arg list
where count // Use immediate integer
where -var varname // take the count from the symbol table
where -local argindex // take the count from the local arg list
Now that is inefficient object code, requiring an entire subroutine to execute the basic loop. But this is interactive scripting, command and control, not the data path. I don't care, I just want enough of the c syntax I need and a clear path to implement the rest of the c syntax as needed.
Notice that most arguments simple point back into the original source string. I force the subsystems to do their own conversion. This is a very flexible approach, but a bit dangerous. I think it justified. Some ad hoc csub systems will want to use the var and local formats, fine, but not necessary, they can be unique in handling arguments except args[0], the cmd identifier. They still have local definitions for flag names.
Notice that most arguments simple point back into the original source string. I force the subsystems to do their own conversion. This is a very flexible approach, but a bit dangerous. I think it justified. Some ad hoc csub systems will want to use the var and local formats, fine, but not necessary, they can be unique in handling arguments except args[0], the cmd identifier. They still have local definitions for flag names.
But, we can see that the args[] as a list of executable primitives is treated like an assembly language. The command handler, as well as idiosyncratic subsystem commands, will treat the args list as a stack, manipulating its contents.
The key here is that I selected a simple parser concept knowing that my execution unit will be ad hoc c routines. Hence the simplicity of the parser, it only add about 50 lines of code to shell. The main simplifier is a single table of c keyterms making it easy to 'two pass' the script. I have traded efficiency for simplified parsing, shortening the complexity of the shell. The productivity gain comes from the simplicity of filling in ad hoc stub routine for the various c syntax elements used. All developers understand the linux argument format. We get a kind of cut n paste architecture for the shell, and a simple general purpose framework.
The key here is that I selected a simple parser concept knowing that my execution unit will be ad hoc c routines. Hence the simplicity of the parser, it only add about 50 lines of code to shell. The main simplifier is a single table of c keyterms making it easy to 'two pass' the script. I have traded efficiency for simplified parsing, shortening the complexity of the shell. The productivity gain comes from the simplicity of filling in ad hoc stub routine for the various c syntax elements used. All developers understand the linux argument format. We get a kind of cut n paste architecture for the shell, and a simple general purpose framework.
No comments:
Post a Comment