NGS: Next Generation Unix Shell
github.com
NGS: Next Generation Unix Shell
1–10 of 204 posts
Re: NGS: Next Generation Unix Shell
#2IMHO the world does not need another Shell language. Please not... it's even sometimes complicated with ZSH & FISH today. A shell which behaves totally different will get me totally different problems than nowadays... no thanks. I know my "enemy and friend" Bash and it's a good thing I get it nearly everywhere.
Re: NGS: Next Generation Unix Shell
#3I don't think there's enough that needs fixing in the current shells/terminals that require a new paradigm at the moment. These things seem to come and go without much adoption.
Sorry, bit negative of me - it's awesome that people are trying.
Re: NGS: Next Generation Unix Shell
#4A shell is an application that provides system interaction to users.
> What I see is a void. There is no good language for system tasks (and no good shell). What's near this void is outdated shells on one hand and generic (non-DSL) programming languages on the other. Both are being (ab)used for system tasks.
Aside from the, in my opinion, abhorrent word "outdated" (why are old things considered bad just because of their age?), the comment about there being "no good shell" is something I disagree with very much. Personally I'm really fond of zsh and its manual pages are a treasure trove. But, lest this digress into a flamewar about shells or into a non-productive discussion about preferences, the point I would rather make is that the author provides a different thing than, as it seems to me, qualifies as a shell.
For example, the open issue mentioned in the README is:
Open issue: how to deal with a command that requires interaction.
As a Linux system administrator I am happy with the tools I have, and initiatives such as this seem to digress into the realm of the programmer. Sysadmins and programmers (a.k.a. developers - though I'd consider myself a developer too but not a programmer) tend to have very different perspectives about how to get an application onto the environment on which it runs, within the greater system of servers and networks.
In that sense, Docker and such mostly seem to get a preferential treatment from programmers, while sysadmins (again, as it seems to me) tend to dislike these kinds of abstractions. And I often get the impression that developers haven't got as much appreciation for sysadmins and what they do, as vice versa, but this could be false, or even more likely is that this is true for some and false for other cases. OMMV.
NGS might be a very useful project, I'm not at all negative about the project itself. It just seems more useful to programmers than to people like me who enjoy nothing more than to interact with their command line interfaces a.k.a. shells.
Re: NGS: Next Generation Unix Shell
#5A shell is an application that provides system interaction to users. > What I see is a void. There is no good language for system tasks (and no good shell). What's near this void is outdated shells on one hand and generic (non-DSL) programming languages on the other. Both are being (ab)used for system tasks. Aside from the, in my opinion, abhorrent word "outdated" (why are old things considered bad just because of th…
I'm suprised you can't think of problems you currently have with shells. Here is a few of mine:
* Once I've started a program, and easy way of sending it to the background if it is taking a while, which sends it's output to some buffer I can refer to later, rather than continuing to spew it all over the screen.
* While we are at it, stop spewing the output of multiple programs over the screen, under any circumstances.
* Have some simple, easy to follow rules which let me work on files that have spaces in their names, without having to remember the various commands with various special cases (like -print0).
Re: NGS: Next Generation Unix Shell
#6> The problem with outdated shells looks pretty clear: they were made with one kind of tasks in mind but are used for other, bigger and more complex tasks. Such scripts usually look as a fight against the language and working around it much more than using it to solve the problem.
Mind you,
> Create a shell (in that language) that is up to date with today's tasks - cloud, remote execution on a group of hosts.
I'd rather create another DSL/tool to solve it.
> Two languages actually.
> Current-shells-like but simplified (called "commands"), $(...) syntax
> Scripting language, "normal" programming language (called "code"), {...} syntax
Good luck.
> The scripts that I've seen (and written in Python and Ruby) look too verbose and show unnecessary effort. Such scripts do not look an optimal solution (at the very least).
Did you check scsh? (I don't use it.) http://scsh.net/docu/html/man-Z-H-3.html
Re: NGS: Next Generation Unix Shell
#7Looks quite interesting! Some feedback:
Yes, a new paradigm for interacting with text commands would be wonderful. But what would that look like?
One strong advantage of the current system is that the input matches the interface. Everything is text, so it all can be typed with the keyboard. But if this shell "displays structured results as real fing structures (YAML, JSON, ...)", that may not be true. If the shell spits out a table, is it a CSV table? A YAML / JSON nested array? How is the user supposed to edit it? The interface isn't clear, and any layers at all are going to take some thought to be able to compose naturally with other tools. (The author addresses part of this with "All operations made via a UI, including mouse operations in GUI must have and display textual representation, allowing to copy / paste / save to a file / send to friend.")
Another thought: from the proposal in the README, it isn't super clear which tasks the author feels the shell ought to handle versus which tasks should be handled by some other toolkit. For example, the "Manage multiple servers at once" subsystem is handled by other devops tools like Ansible or Chef at the "deploy an application" layer and tools like Tmux or 'clusterssh' at the "send input to multiple processes in many screens at once" layer. Another example: the author proposes "Actions on objects that are on screen. Think right click / context menu.", but since these actions must require cooperation by the program being invoked, it's not clear whether this serves the purpose better than simply wrapping that program's operations in some GUI toolkit.
This could be pretty interesting, but I wish the author would formalize some of this thinking into a concrete standard. Having too big of a vision without some set boundaries seems to be hurting the focus of this promising project.
Re: NGS: Next Generation Unix Shell
#8Lots of assertions about how "bad" our current shells are, but no substantiation. I'm a developer, and I know just enough shell to write a simple deploy script or two, but reading this, I'm not convinced that what we really need is new shells and scripting languages.
Re: NGS: Next Generation Unix Shell
#9I'm sure we can all agree that the current state of shells needs some work, but I don't think inventing a new one is the right solution. I'm a huge fan of the fish shell, but in the real world, it never seems to be installed across the farm, and convincing the older SysAdmins to install it is more trouble than it's worth.
We should be focusing on saner bash defaults, since it's the most common shell in use. We shouldn't have to remember these large list of gotchas, and pitfalls that shouldn't be there in the first place. A few people out there are trying to recreate common utilities such as ls or cp, and while I welcome the change, I feel it should be part of the actual gnu coreutils package, and not a new project: https://bsago.me/exa/
Re: NGS: Next Generation Unix Shell
#10A shell is an application that provides system interaction to users. > What I see is a void. There is no good language for system tasks (and no good shell). What's near this void is outdated shells on one hand and generic (non-DSL) programming languages on the other. Both are being (ab)used for system tasks. Aside from the, in my opinion, abhorrent word "outdated" (why are old things considered bad just because of th…
I'm suprised you can't think of problems you currently have with shells. Here is a few of mine: * Once I've started a program, and easy way of sending it to the background if it is taking a while, which sends it's output to some buffer I can refer to later, rather than continuing to spew it all over the screen. * While we are at it, stop spewing the output of multiple programs over the screen, under any circumstances…
For the first two issues, I use tmux. If something is long-running, I open a new shell to continue working. If I want to run multiple related commands, I can open many shells and have tmux send my keystrokes to all of them.