1. Save lines to be repeated in memory
2. Save position in file where body of repeat starts, and seek back to that position upon repeating.

What about nested loops?

Vid, my plan was to completely extract data from the file an store it into memory (a reserved variable), then parse that data.

revolution, a nested loop? A good idea.

Do you mean like this:

Could I first parse the loop. Allocate every inside { } to memory for later use.
1. Check the steps in the FOR loop (1 - 5)
2. Set a counter, from 1 to 5 (simple).
3. Call routine that evaluate allocated data from { }
4. if .ENDFOR is found, then jmp to loop
5. if count = 5 then break loop (steps are completed)

Why do some commands start with a dot (.) and some not?

The dot will allow the CLI to easily recognize the end of a statement or loop (.ENDIF, ENDWHILE, ENDFOR) so that the shell doesn't think it is another just command

Both .start and .end are not necessary, but I just thought I should add something to them to the script skeleton.

It looks inconsistent with the dot only on some commands. Perhaps you can put it on all commands. It would make the syntax look a bit cleaner.

Would it look cleaner without the dot, or with it?

Maybe 2 dots would look quite good?

..command

or 3?

...command

Dot is not needed unless to avoid naming conflicts.
Plus you get to save 1 byte for every command name.

I thought it would have been easier if the dot was there to identify a final keyword, but I could change it.




When a control flow statement is called then the final keyword will be added. Each is handle for each command. This avoids for the final keywords to be included in the command structure.

Easier for whom? For you to implement, or for people using your script to write?


Doing it this way, How exactly does the nested-command-handling-routine know that "ENDFOR" matches "FOR", "ENDIF" matches "IF", etc?

it lokks like a XML concept.

it means a tag approach to reach the IF ... ENDIF goal.

but, why a IF in a command line? cannot the command itself contain IFs, WHILEs and FORs inside its own code, and user be aware of that when using the command?

vid: it would be easier for me to implement, and the shell to process. There will be no need for the shell to have to parse the command list, then try and find the an end tag.

It could also be useful to the users where they could know where an
and control flow structure ends. I don't know how the dot would affect the aspect of the script.

To find a match, the interpreter would simply scan and collect the instructions into memory starting from then colon (: ) FOR A = 1 TO 5:
But first it stores the command name into FINAL_KEYWORD, for later use.

When a dot (.) is found the engine scans for "END" then for the compares the remaining sequence. It match the character to the command in FINAL_KEYWORD. If it matches the interpreter jumps back to the start of the data, and begins to execute each command.

edfed: An IF command is necessary in any programming language (from my point-of-view). It allows users to allow the script to make decisions, depending on the condition provided.

I have not thought of how I could allow nesting of another construct. Could you provide some ideas?

Do you think I could just use } (right brace) as the .END* replacement?

a CLI is not a programming language, it is a comand line interface.

a programming language is more like fasm , you write the source, compile it, and execute it. or interpret it, or emulate it.

command line is only a line, not a page of commands with loops and if everywhere.


if you need some looping for your command, or conditions, you can play like in some linux CLI (shells), with a one line - multi instructions

i don't know the exact syntax, but it looks like this:

if A=0;write bootsector A+1

and then, you see one thing, it is completelly useless to do programming with command line.
in my point of view, programming is with a text editor and a compiler, then, a program.
comand line is to manage these programs, not to program these program.

it is like a strange design.

then, start with a ONE command at a time CLI, and maybe later you will find how to make a multiline, multi instructions, multiconditions CLI.

first, simple CLI, after, you will see how to do a complex design.

edfed: http://en.wikipedia.org/wiki/Common_Language_Infrastructure

but... the title of the thread is Command-Line Interpreter.

isn't it?

edfed: http://faydoc.tripod.com/cpu/cli.htm

http://en.wikipedia.org/wiki/CLI

and in french page, CLI is a french (paris) tagger that draw on trains.

I know that it isn't a programming language, it is a scripting language. Something like batch files.