Hello, Supragya, thanks for your comments. 2017-03-27 19:50 GMT+02:00 Supragya Raj <[email protected]>:
> !~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. > Okay. IMHO it is still too complicated (that is why I like the Unix approach where you not only learn what language it is but the shell also knows where to find the interpreter) but really this is not crucial. 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. > Just to make things clear. The system wide variables would be global? I.e. the script changes them and all tasks would see the new value (after invoking some getenv-style function)? I am still concerned that if I would like to, for example, extend $PATH, I really do not want to extend it for all tasks in the system. Practically, I am speaking of the following trick (hack) that we use regularly when porting software to HelenOS. You extend $PATH to point to your directory where gcc script is. That is actually a Bash script that adds some extra arguments and calls the appropriate cross-compiler. In this scenario, I want the the configure script and its subprocesses use this extended $PATH with fake GCC. But I do not want other apps in the system to see this variable at all. Maybe I missed something obvious. Do you have some counter example where the behavior you propose would be useful? 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? > IMHO maps (dictionaries, whatever name you like) are very useful. Actually, you do not have to implement them but I would like to prevent situation that happened in Bash where arrays were added later and the syntax suffered. > > >> 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. > I would say GCC is also GPL and we happily use it to compile BSD-licensed code. And you will not include source code of Bison, only input for it. 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? > Bdsh is really very primitive shell - I do not think we need to be backwards compatible with it at all. AFAIK the only Bdsh scripts we have are those for running ported GCC with the right flags. Personally, I would not mind dropping Bdsh if we have something more powerful yet usable as normal shell :-) > > 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. > You lost me here. 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? > I am merely asking how you suggest to write I/O redirection, e.g. whether to use <, >, >> as they are in Unix or reuse Bdsh syntax or something completely new? 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? > I still think you underestimate the complexity involved here. I understand the motivation and the simplicity for some of the commands. Still, I would rather see maps or parallel execution in a scripting language than this :-). 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. > I never meant to take credit for the idea :-) 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? > As I wrote above - I would really remove the part about transactions and if you leave Bdsh alone, there will be some changes. One more thing came to my mind. I would really like to see more examples of what the shell would be able to do. For example, at [1] we have FS test that "Create 2M file on /tmp/img, file_bd img fbd0, mkfat fbd0, mount fat /data fbd0, copy some stuff to /data, do something with it, unmount, see it's not there, mount again and verify the contents is there again." Would it be possible to translate this to an automated script to check this? How would the script loke like? [1] http://www.helenos.org/wiki/ElasticHorseRegressions Thanks! - Vojtech > > 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 > >
_______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/listinfo/helenos-devel
