Open b9Joker108 opened 2 months ago
ilyash-b
commented
2 months ago I'll take another look given more interest. At the moment it's hard to estimate the amount of work.
I'm not sure how much value will be unlocked here though. That's because NGS is currently only a programming language. The work on UI is in early stages and from the terminal & web interfaces, I've started with the web because it's easier to implement.
Let me know what you think, @b9Joker108
Thanks!
b9Joker108
commented
2 months ago Oh, so if I understand you correctly, NGS isn't truly a 'shell' at the moment, as there isn't yet an interactive shell application component, it only consists of a scripting language, at this stage. Is my understanding of your comment correct? Or, is there actually a shell implemented in a Web-application? My comprehension of your comment may be compromised, and by extension, my interpretation, of your comment, is ambiguous.
Moreover, upon investigating your project, I note that the NGS language has been expressly and purposefully written, for systems/network administrators, to fill a manifest void, that the current toolset isn't addressing, in any concerted way.
Please, permit me a segue. For the last six months, I have been writing solidly, full-time almost every day, a book on the history, development and evolution, of the computation shell, particularly in its Un*x/*NIX evocations, for a work that principally focuses on my personal experience, acquiring interactive and shell scripting skills for POSIX-compliance, Bash and Zsh, and making my learnings a road-map, for others to follow.
The work focuses on Termux, specifically and particularly, and its principal audience, are the newly digitally included, amongst the third of the world's population, currently digitally excluded. Though, of course, the work will be of relevance to others. The book has grown and evolved in scope. Initially, it was only a personal learning journal, that started as a page, in one of my personal knowledge management systems, though has long-since outgrown that form but not in function, was subsequently developed in a GitHub repository, outgrown their Web-application's capabilities, and I am now developing it with Gitbooks, integrated with its GitHub repository, and it is currently not even at pre-first draft stage. It is already at a length of in-excess of a thousand standard print pages.
Moreover, I currently have circa eighteen (18) shells installed in Termux, listed alphabetically by executable: ash, bash, bsh, cicada, csh, dash, elvish, fish, ksh, mksh, nu, rc, tcsh, tsh, xonsh and zsh and two shells within the Termux version of the Busybox application. So, I was really excited, to prospectively add ngs, into the mix, and document it within my work.
In researching, writing the work and documenting my experiential shell-agnostic, interactive and scripting endeavours, I have come to see and perceive them, as an ecosystem, rather than as discrete or separate, and each has positives and negatives, advantages and disadvantages, possibilities and limitations, and as such, they each have their own specialisations and usecases, and communities. It is further to this, that your project's language and its purpose, piqued my interest, as I have come to appreciate that the vast number of systems/network administrators statistically favour the Korn shells family, for scripting, and as an interactive shell.
This surprised me somewhat, as I have not read it, I discovered it from anecdotal evidence, whilst trawling Internet communication threads, specific to the topic, and extrapolate statistics by extension, due to the significant sum, of anecdotal evidence. As a number of the Korn shells are still in active development, yet constrained by philosophy, language, historicity, implementation and development, having a domain-specific shell and shell scripting language, purpose built, to take the torch or baton from the Korn shells family, will cement your project's relevance, and ensure its uptake, albeit niche market.
All this is probably, far too much information, and you are probably, otherwise busy with your projects. But, I still hope that an installation script for Termux that doesn't mandate sudo, may be forthcoming, in the first instance, and that packages within the Termux repository, may follow.
I await your advice, in due course.
Best of luck with your endeavours, and in realising your projects.
Thanking you in anticipation Beauford
ilyash-b
commented
2 months ago Hello Anton,
Excuse me for my delayed reply.
Oh, so if I understand you correctly, NGS isn't truly a 'shell' at the moment, as there isn't yet an interactive shell application component, it only consists of a scripting language, at this stage. Is my understanding of your comment correct?
Correct.
Or, is there actually a shell implemented in a Web-application? My comprehension of your comment may be compromised, and by extension, my interpretation, of your comment, is ambiguous.
The web UI is in such an early stage that I don't imagine it can be of interest. Here are the closest things:
I would like to mention the reason it took so long to get to the UI. The programming language had to be ready (enough) to be used to implement the UI. Most of the UI is being implemented in NGS language. For me, it makes sense that a user of the shell, once decides to contribute to UI doesn't need to learn another language, which is the case in many (if not all) other shells.
Both UI plugins (Web, terminal) should have minimal amount of code on the client side. In case of web, that minimizes the amount of JavaScript. Such layout, among other things, minimizes the chance of needing to modify anything on the client side (using not NGS language in case of web).
At the moment, NGS implements JSON-RPC on a Unix socket for the server side. Web UI connects to it through a proxy. I was not fond of the idea of having an HTTP server on NGS side, hence JSON-RPC and proxy.
Moreover, upon investigating your project, I note that the NGS language has been expressly and purposefully written, for systems/network administrators, to fill a manifest void, that the current toolset isn't addressing, in any concerted way.
Yes. Just before starting the project I was frustrated with absence of a programming language specifically designed for DevOps. It was not an abstract frustration. I was using bash and Python. I felt that both were bad fit for what I'm doing. That's how the project was born.
More at my blog post bash or Python? The Square Pegs and a Round Hole Situation
perceive them, as an ecosystem
This is at least correct for NGS. Being a part of the ecosystem manifests with having integration facilities.
One group is for running external programs from NGS: constructing command line arguments (seems unique to NGS, https://ngs-lang.org/doc/latest/generated/Argv.html ), handling of exit codes (seems unique to NGS as it distinguishes error exit codes, which are not always any non-zero), parsing the output (syntax as it's frequent operation).
Second group are facilities that make it smoother to invoke NGS scripts: automatic command line arguments parsing, namespaces are mapped to nested commands (again with automatic arguments parsing), easy definition of how to translate an object to an exit code ( https://ngs-lang.org/doc/latest/generated/ExitCode.html ), command line switches for formatting the output when running an expression (ex: ngs -pj [1] + ["aa"] would print JSON array with two elements)
About the ecosystem and other projects:
While it looks like there as agreement that the programming language of let's say bash is a problem, it doesn't seem to be an agreement of how to solve it. NGS takes the approach of fully fledged programming language with addition of domain specific syntax and facilities.
On the UI front, NGS goes for the sacred cow. Outputs of commands should be parsed, understood by the shell, and be interactive in order to help constructing the next command (roughly). It's amazing to me how people are drawing the line between understanding of inputs (which is being done today, required by the loved command line completion feature) and understanding and interacting with the outputs (which is "the shell is not supposed to do that"). This telegrpah-style send-text-receive-text communication paradigm, one of my biggest frustrations with the shell, should go. Treating outputs of programs as if they were printed on paper, allowing zero interactivity, is not the pinnacle of UI as I see it today. More at my Unix shell - We can do better now Conf42 talk.
installation script for Termux that doesn't mandate sudo, may be forthcoming, in the first instance, and that packages within the Termux repository, may follow.
I'll try to look at it as time allows. I hope it's only the sudo issue which shouldn't be time consuming to solve.
Best of luck with your endeavours, and in realising your projects.
Thanks!
To whomever it may concern
I have great interest in your project. I was not aware of your project, prior to reading a Nushell Discord post, from one of your principal, or core, project developers, in their introduction thread post, stating that they were scoping the competition. So, as a consequence, I came looking for you.
I note, that your project makes no reference to a possible installation on Termux. I also note, that all relevant installation options, seem to mandate
sudo, as standard. On my current Termux daily driver, I am unrooted.So, I felt I would venture the installation script anyway, even though knowing, it would be unsuccessful, which it was. I would really appreciate if you would subsume Termux, within your project purview, and make available, an installation script, appropriate for a non-rooted Termux environment, if possible.
Furthermore, I searched your repository, and found mention of this closed issue:
https://github.com/ngs-lang/ngs/issues/535
I really hope that packages of your project come to the Termux package repository, for the four (4) principal Android architectures, with haste.
Best of luck with your project.
Thanking you in anticipation Beauford