Thank you for feedbacks Vojita, here are my views on implementations of
your queries:
I will start with a very generic question; I tried to keep the rest of the
> comments sorted as in your proposal.
>
> What you expect would be stored in the variables? Obviously, the l$var are
> plain variables to be used in the scripts, but what about the rest? Would
> we use them to store things like $PATH only or would they serve as a
> generic configuration storage (e.g. like registry in Windows)?
>
> Generic configuration storage will be done by env_server system. and l$var
is just for the script scope only. Everything related to script, may it be
integers, float, doubles etc will be stored in the local variables as
l$var, like a normal programming language does. However, as of now I have
planned to implement env_server as a simple string storing system only.
This models UNIX style env var storage.
> !~script notation. The inspiration by Unix #! is obvious but I miss how
> would you distinguish different languages (or their interpreters). Why not
> to stick with the Unix format here? But this is a minor thing only.
>
It is definitely not a big thing and is just for the sake of verification
whether the script is okay to run or not. I have mentioned in the proposal
the following lines:
*The checker of this system would however be a separate function upon
implementation that may return a bool value - true if it finds (!~script)
in the header, false otherwise. Hence, any future updates altering this,
would be easy to incorporate.*
The checker system is just an init testing *"function"* that will be
incorporated. It can be coded differently to check different set of
characters. As you said, surely #! can be used. This is what are the future
updates I talk about. A few other future updates that I have in mind are
HelenOS core system able to store permissions in some UNIX style format
-rwxrwxrwx type. This need not be straight UNIX style only. However, then,
it would no longer be required to check explicitly whether the script is
executable or not. This will be undertaken by the the core system itself.
In that case, checker function may not be needed to test for executability.
Then, the function would just be used to check for the language selection
at best or can just be scraped off - this I have in mind, that is why it is
a separate independent function. For distinguishing languages, a simple
solution is possible, as checker is init function, we may return from it an
enum value. enum would have codes for different languages. And checking of
which language the script is will be a mere strcmp. How? In those cases, we
use UNIX like approach. for language A #!-LANG=A and for B #!-LANG=B may be
used. This would let init decide which interpreter to spawn if further
languages are incorporated.
>
>
Variables and scopes. On one hand I like the idea of explicitly specified
> scope but it seems to me as actually not very practical. Consider for
> example some equivalent of $PATH. Sometimes you want to modify system-wide
> settings, sometimes you want some changes to be for current process only.
> Then the script would need to check for both e$PATH and b$PATH before
> running anything which is not very straightforward. Not talking about local
> variables in functions.
>
> Just by the way, I would stick with system-wide variables name instead of
> environment, because for Unix world, your *bdsh-instance variables are
> actually environment ones.*
>
If that is acceptable, I would really like to scrap off the idea of b$
variables. I too, thought this was a terrible idea, however thought this
might raise questions. Done, we may have just two scopes now.
> Which types do you plan to support and how? Because in 1.2 you wrote that
> "everything is a string" yet many of the examples use integers. Would there
> be some kind of automatic conversion (as in PHP, for example)? Have you
> thought about some structured types (arrays, maps, ...)?
>
Yes, it would be somewhat PHP like system - for conversion between strings
and other data types. I think UNIX uses the same thing. However, I still
haven't thought about structured data types like arrays and maps. These may
be added. However, I need some time to think over how these would be
implemented. For starters, I think the script language should disallow
usage of pointers. In that case, arrays may be stored using hashed tables
etc. However, I am really unsure about these at the moment. Are these
structured datatypes really necessary in the primitive shell?
> Use of Sysel. Although it is nice to reuse existing code base I would
> recommend to think again whether to re-use Sysel. Sysel was last updated 5
> years ago and AFAIK is for all practical means abandoned. Since you already
> use different syntax in your examples, I do not think that you would reuse
> that much code. Furthermore, I think it is much better to use lexer/parser
> generators (e.g. Flex, Bison etc.) than to write them manually (especially
> if the syntax is expected to evolve).
>
That idea of using Flex and Bison crossed my mind. However I reverted to
existing tokeniser and interpreter because I am unsure about the licensing
parts. As far as my knowledge goes, FLEX and BISON come under GNU which
uses GPL. Somewhere in your contributions page was written that HelenOS is
BSD licensed and that you do not want to use applications under GPL Can u
please elaborate on whether FLEX and BISON are safe to use for HelenOS? If
they are, I am happy to work with them.
> Similarly, I would probably create a new application (i.e. keep Bdsh as
> is). I suspect that the architectural changes in Bdsh would be too big and
> you can always copy functional parts of Bdsh to your app.
>
You brought this idea once earlier at IRC. However, you did not quite
explain what would happen to the present modules and builtins... I said
this would create compatibility problems. By compatibility I meant that, if
new terminal system gets established, there will be two instances of code
(2 mkdirs for example) in the codebase doing the exact same thing. How do
you think we should resolve that? Should both systems use the same module
and builtin system? I don't think that will be a good idea architecturally
because any enhancements that may be proposed in the newer terminal will
always have to be done thinking about compatibility with bdsh which will be
hard. At present time, I think that the code of those modules and builtins
can be reused quite a bit but modifications of them are inevitable. So only
choice would be two instances of code in codebase doing the same thing. Are
the core developers okay with that?
If they are, I have no problems implementing a new terminal system. If not,
can u suggest alternatives?
I have a question regarding your example with l$var1 and pwd. What is pwd?
> Is that a built-in function or do you plan to capture output of a pwd
> command? By the way, how do you plan to support functions?
>
Exactly, that is a builtin function whose output I would like to capture
out. This would require a buffer like stdout and stderr in the system, the
assignment can be done by releasing that buffer. During execution of
processes, the following lines are executed:
files[0] = io->stdin;
files[1] = io->stdout;
files[2] = io->stderr;
I think I may add in a new buffer there, and would handle that accordingly
for this thing to work. If done correctly, I suppose that may pave way to
establishing primitive pipefs too, however not concurrent at the present
time.
> Related to this: do you plan to reuse the IO redirection syntax from Bdsh?
>
Not really. The above is what I have thought of. can u please elaborate on
what parts are you quoting?
> System restore: I really like the notion of transactions but I do not
> think that it is that simple. Although I understand that touch/rm served as
> a mere illustration it shows well the complexity of the problem: you would
> need some kind of snapshot support from the file system merely to allow
> rollback of FS-related operations. That alone would be worthy a GSoC
> project. So although it sounds very interesting I would remove this from
> your proposal.
>
Even when proposing this, I knew this question will be raised. Just for
your knowledge, I am not proposing to implement that system fully or even
to the extend that may be called partial. However, in the terminal, would
provide with provision for this system. At the present moment only problem
like the one presented in illustrations may be handled. Later, this may
include storage of diff formats just as VCS's do. However, I may not
undertake those tasks in the given project, I may just keep that in mind as
I build the system: part of codes may invoke a function that may just
handle things for the time being (like pipefs in bdsh, not implemented but
provided provisions for). Is that okay to be put in?
> Variable management and storage. First of all, I would keep separate the
> POSIX-like environment variables that has very precise rules for scoping
> and inheritance among processes: implementing this as a separate server
> seems to me as a sensible solution.
>
Thank you. I thought this would be a plausible option because of things
that you just described. Btw, his was proposed by Jakub Jermar.
> Second thing - implementing any variable storage like a file on a tmpfs
> looks like a bad idea. Either implement that in Bdsh directly or have a
> special server for that.
>
Sure thing, that was my initial idea. What you described is my idea right
now. tmpfs will be slower I understand. Won't do it that way. It will be
implemented as memory in the interpreter itself.
> Regarding your time-line. I think that it is basically okay but maybe if
> you decide to change the way variables are stored (i.e. get rid of that
> tmpfs approach) and remove the anti-command subtopic, some changes would be
> necessary.
>
I provided you with my ideas on your queries. What changes do you still
think are required, can u please provide?
Thank you for your comments. Would really wait for reply to this mail.
Also, as Jakub adviced, I may soon take the proposal online. Would send you
a notif as soon as I do it.
Thank you,
Supragya Raj
_______________________________________________
HelenOS-devel mailing list
[email protected]
http://lists.modry.cz/listinfo/helenos-devel
