Hi Supragya Raj,
"On 04/27/2017 08:19 AM, Supragya Raj wrote:
> This concept brings to one more thing... since the C implementations of
> libraries can directly talk to vfs and do all things behind, how do
> shellecho like *<% mkdir newfolder >* are handled - using such internal
> implementations of C libraries or any other way? I would say there are
> two ways of handling this - after making the substitution in these shell
> commands like *<% mkdir {$var} >* , we may send this for execution to
> bdsh - or handle it ourselves and talk to system directly - using self
> implemented mkdir and a list of other commands. I thought over it and
> here is what I decided finally (I may be wrong) - Send all such
> execution requests to bdsh - this allows a few things - for one, the
> interpreter would never have to worry about implementations of redirects
> and pipes, since they will be handled the way bdsh handles the current
> commands of such types. Any output request that you may need from such a
> command can be easily done - whenever HLang calls bdsh - it asks to save
> any outputs to a file and send it back to interpreter (through IPC or
> other ways). This data (outputs) can be gathered and brought back into
> the script using again - a library function designed specifically for
> this - something like *declare $var = HL_STDOUT("<% cat helloworld.cpp |
> grep hello >"); *This command calls library function - which internally
> calls shellecho (shell.c) with a message notifying that output may be
> required back - this is then sent to bdsh and output is captured and
> given back to HLang (obvious modifications are needed in BDSH). This
> frees up the language from worrying about pipes and makes use of
> available infrastructure. However, this is not maybe what some of you
> want - given BDSH is something you want changed. In that case, HLang can
> itself handle execution fully without bdsh - just it would need another
> module that services shell.c and implements all commands such as mkdir,
> cat etc. Also in that case, the syntax never changes - you still use *<%
> mkdir {$var} > *without worrying whether it goes to bdsh or to internal
> HLang implementation of mkdir. "
I think you are thinking backwards here... If we have a shell command/
automation language, then the shell (the user interface) and the language
can (and probably should) be two distinct entities (executable and library,
respectively). When you enter a command into the shell, it will pass it to
the language parser for parsing and execution. Now it only makes sense that
the language library implements all the language primitives, including the
built-in commands (mkdir, etc.). This means that, if you decide to split the
language to a library, you will effectively move the implementation of the
built-in commands to this new library (or do a fresh implementation, if you
prefer. In any case the shell would not implement it itself anymore).
Cheers,
Jiri
"
"
_______________________________________________
HelenOS-devel mailing list
[email protected]
http://lists.modry.cz/listinfo/helenos-devel
