JdBP>> I'm writing an interpreter "engine" for command scripts (a.k.a. 
 JdBP>> "batch files").  The idea is that one can link CMDAPI.DLL into 
 JdBP>> one's application and run command scripts and execute command 
 JdBP>> lines in the context of the current process.
 JdBP>> 
 JdBP>> [...]
 JdBP>> 
 JdBP>> I can see a wide variety of uses for such an API, from NC clones and 
 JdBP>> YAOS variants that no longer need to "shell out" to run commands, to 
 JdBP>> novel approaches to specliased command interpreter programs, such as
 JdBP>> NSLOOKUP or an FTP client, giving them the scripting, redirection,
 JdBP>> environment variable expansion, and pipelining abilities that they 
 JdBP>> so often lack because their own interpreters are comparatively 
 JdBP>> primitive.  [...]

 ET> I'm curious, what advantages has this above REXX ?

Advantages apart from the fact that the REXX interpreter interprets a
*completely different language* and so isn't suitable for any of the tasks
listed in the examples above ?

If one is writing an application that needs to execute command lines, up until 
now one had only two options:  one could "shell out" and spawn a child command 
interpreter process to handle command lines, or one could hand-roll one's own
command interpreter.  Choosing to shell out leads to difficulties with
commands such as SET, PROMPT, and CD not appearing, to the user, to operate
correctly.  Choosing to hand-roll one's own command interpreter is expensive
on the other hand, and often such command interpreters are limited in
function.  Look at most command-driven FTP clients, for example.  They appear
and behave like a command line, issuing a prompt and responding to commands,
but they often lack even the most basic things, like the ability to redirect
the output of commands to file, the ability to combine commands into pipelines 
or to execute multiple commands on a single line, or the ability to use
environment variables in command lines.

With my CMD interpreter engine an application developer now has a third
option: use the interpreter engine to interpret commands.  The engine provides 
a complete implementation of the CMD language, which has benefits to the
developer and to the user.  The developer doesn't have to hand-roll their own
command interpreter at all or hand-roll their own built-in versions of
standard commands such as SET and CD, and the user gains from the fact that
*all* of the features of the standard command interpreter are now present and
available for use if needed.

 ¯ JdeBP ®

--- FleetStreet 1.22 NR