The github page links to a screencast which I found more helpful than the github writeup itself:
NGS: Next Generation Unix Shell
21–30 of 204 posts
Re: NGS: Next Generation Unix Shell
#22But why nodejs?? There are a lots better languages to base this off ove.
Re: NGS: Next Generation Unix Shell
#23But why nodejs?? There are a lots better languages to base this off of.
Re: NGS: Next Generation Unix Shell
#24Something I would LOVE to see (not only in a shell but in all tools) is some kind of "project mode". - In Chrome/Firefox I'd like to have a mode for recreational browsing, one for research of webdesign and one for fitness/health stuff. This basically means that I want to click at a browser window and say "This is now my fitness window. Please remember all the open tabs". And then there is a list of open sesions/proje…
Chrome has this feature already, with the concept of Persons. I have a "Work" person and a "Home" person, which gives me a different set of cookies, extensions, pinned tabs etc...
I know about persons but I'd like to share my cookies and other stuff between all my "projects". I tried to use it but it is too separated for my uses.
Re: NGS: Next Generation Unix Shell
#25A 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…
issue 1) sounds like you miss nohup, sreen or tmux in front of that long running program.
issue 2) usually I don't have one terminal session with multiple programs doing output at the same time, this solves this issue.
Just use a new xterm, a new terminal tab, a new screen tab for programs that are going to produce output and stay running.
issue 3) I think you refer to files with other special characters, because spaces on filenames do not need -print0 at all, simply proper quoting in the code will do.
Regarding issue 3, there is a lot of caveats when coding shell; even file names starting with a dash (-) which are interpreted as options by tools external to the shell (which fortunately support a double dash (--) to stop processing parameters).
Re: NGS: Next Generation Unix Shell
#26Just because something has been around for a long time it doesn't mean that it's outdated. On the contrary, it means that it's stood the test of time, which is usually a sign of a good design.
Re: NGS: Next Generation Unix Shell
#27I'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 should…
If it's hard to try to convince them about fish... try to convince them to enter commands in a browser over a web stack, as a "shell".
If they are conscious about the parts involved and the security repercussion, maybe they will say the same: "no".
On the other side, technology is not advanced only by older SysAdmins, and it's nice to see new projects, experiments and developments.
Re: NGS: Next Generation Unix Shell
#28So, this project starts about shell, then I see it also aims to implement full-blown terminal emulator and a lot of new very ambitious features, and then it invites terminal-based apps to use new capabilities of it, so it would be best usable only if the whole ecosystem of compatible apps appear. Unfortulately, I'm pessimistic. Also, would like to comment on project's README. Not meaning to be harsh. > The shells nev…
"So, this project starts about shell, then I see it also aims to implement full-blown terminal emulator and a lot of new very ambitious features, and then it invites terminal-based apps to use new capabilities of it, so it would be best usable only if the whole ecosystem of compatible apps appear."
This is actually my only objection and the only feedback I'd make to the author. Contra some of the other posters here, I fully agree shell is a mess and that the basic root cause of the mess is that you can not straddle interactive use and programmatic use with one language. But something a bit smaller needs to be bit off.
I'd also suggest that most shells have already got the interactive use case sufficiently covered and that the low-hanging fruit is in the command case. Perl is perhaps the best language that functions as a programming-shell replacement, but using it for a while reveals it still has many significant issues in that use case. Even with modules, it pipes surprisingly poorly. It tends to make stream processing harder than it needs to be, unless "one line at a time" works for you. It's got a lot of nasty syntax that is arguably optimized for big program use cases that doesn't make sense when replacing shell scripts. When being used for shell programming, it basically shares C's abject failures when it comes to error handling, making it range between bizarrely difficult (I have to left-shift the result of system to get the actual exit code?) to almost-impossible-to-remember (backticks) to get errors properly handled. It has no concurrency story or any particular "run on multiple targets" ability (though I confess I don't know what that looks like necessarily; in my head it rather becomes puppet or ansible fairly quickly).
There's room here, but it's going to be an uphill battle.
Re: NGS: Next Generation Unix Shell
#29I suppose all of the behavior should be highly customizable. It would be nice if plugins could be written in any language. For example, I expect special CLI editor extensions for editing JSON input to programs (with syntax highlighting if desired). Also, I expect specific key-bindings (for e.g. vi/emacs modes) to be pluggable.
Re: NGS: Next Generation Unix Shell
#30A 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…
Just use tmux. It'll take a day to figure out, and then all your problems go away. Well, save the spaces, that's never going to happen.