Actually... bash is a pretty solid language since version 4, just no one takes time to learn it.
NGS: Next Generation Unix Shell
31–40 of 204 posts
Re: NGS: Next Generation Unix Shell
#32Earlier quoted context omitted.
Those can all be seen as tweaks to existing shells. With regards to... "* 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)." I'm not sure I understand what's hard about files with spaces in their names. I'd say it's easy enough to work with such filepaths by using tab autocomplet…
When you pipe the output of one command into another, e.g 'ls | wc' (obviously a dumb example), the second command will split the filenames on spaces and so will not run properly. The workarounds for this all involve nasty extra parameters for different commands (e.g. the -print0 example)
ls is not bash
wc is not bash
And that is a discouraged way to count files in shell script.
Still, simply adding -l to ls, could handle spaces correctly (the files count)
I insist, spaces are not your enemy, there are much more weird file names for a shell. Shell can handle spaces if used properly.
Re: NGS: Next Generation Unix Shell
#33For me a next generation UNIX shell needs to catch up with what REPL environment in Lisp Machines, Interlisp-D, Mesa/Cedar, Smalltalk, Oberon(-2), AOS features and capabilities. For the young HNers, think having something like Swift Playgrounds or IPython as your shell, while having full access to the OS API without relying on external programming languages. Otherwise the next generation prefix isn't worth mentioning…
Something like TempleOS, written in Holy C?
Re: NGS: Next Generation Unix Shell
#34For me a next generation UNIX shell needs to catch up with what REPL environment in Lisp Machines, Interlisp-D, Mesa/Cedar, Smalltalk, Oberon(-2), AOS features and capabilities. For the young HNers, think having something like Swift Playgrounds or IPython as your shell, while having full access to the OS API without relying on external programming languages. Otherwise the next generation prefix isn't worth mentioning…
And arguably you'd have to call it last-generation as well, if you recall how long ago those innovations happened but never made it into mainstream. That would label current shells as dark age of tty :). I still cannot accept the fact that we use tty emulators.
Re: NGS: Next Generation Unix Shell
#35Having read through the readme, I think some of the issues outlined could be solved by having a cell-based model like jupyter/ipython.
Basically a command (input) and its corresponding output are tied together as a "cell". The UI could be very like the ipython notebook, where you have a text box for command input and then above it you have a chronological list view of cells. You would also have a good keyboard-shortcut language for navigating back and forward in the cell history, so you could, say, go back and focus a cell which has been running for a while and is now prompting for input.
(Edit: imagine a key sequence like `Alt-b, Alt-b, Ctrl-Enter` meaning "go back two cells and give text focus to that cells input field.". In reality you'd probably want a command language that's more vim-like.)
The cell model would also allow you to truncate output, minimize or maximise the cell display, and a bunch of other UI tricks I can barely think of right now.
Basically each cell would be a little parallel shell of it's own.
If this sounds even remotely compelling, I wouldn't mind writing up a more formal proposal and submitting it as an issue on the repo.
Re: NGS: Next Generation Unix Shell
#36Earlier quoted context omitted.
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 spa…
This is the canonical writeup about argument injection vulnerabilities:
http://www.defensecode.com/public/DefenseCode_Unix_WildCards...
Re: NGS: Next Generation Unix Shell
#37A 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…
I'd personally like a way to redirect the output of a running process (either `bg`d or `disown`ed) to a log file. The only way I've come across are horrible hacks using gdb[1] or strace.
This should be easier. Anyone know of any better ways? I'd like to be able to do something like `proclog `.
[1]: http://stackoverflow.com/questions/593724/redirect-stderr-st...
Re: NGS: Next Generation Unix Shell
#38I'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…
That's because fish is a better version of existing shells. It's not significantly different to throw away what we have. Sane syntax and proper colors and better autocomplete make it better than bash, but not enough to throw away the network effects of bash. Think of hg trying to compete with git - it might be better, but it's not better enough.
As a shell person (I'm the maintainer of https://certsimple.com/rosetta-stone) NGS offers:
1. non blocking
2. structured results
Doing both of those - if NGS can do it - is a MASSIVE shift over existing Unix shells. Think git replacing svn.
The POC for #1 looks really good: https://www.youtube.com/watch?v=T5Bpu4thVNo
Re: NGS: Next Generation Unix Shell
#39I'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…
We should be focusing on saner bash defaults, since it's the most common shell in use.
For example there should be no reason in 2016 why a sane solution can't be found for having almost every bash installation recognize all keys on the keyboard (i.e. arrow keys wouldn't produce ^A sequences or similar).
Another thing that would be sorely needed but would involve a much higher volume of work would be a template, at least for all GNU utils, which they use to define they options, parameters, arguments, whatever. And by "template" I mean library, actual working code they could include and configure.
Instead of each shell (bash, zsh) having to come with a million small scripts that configure auto completion, these shells could just query the standard-compliant tool for its usage and would receive a standardized reply with everything. Powershell has something like this and it is a great idea.
Re: NGS: Next Generation Unix Shell
#40For me a next generation UNIX shell needs to catch up with what REPL environment in Lisp Machines, Interlisp-D, Mesa/Cedar, Smalltalk, Oberon(-2), AOS features and capabilities. For the young HNers, think having something like Swift Playgrounds or IPython as your shell, while having full access to the OS API without relying on external programming languages. Otherwise the next generation prefix isn't worth mentioning…
And arguably you'd have to call it last-generation as well, if you recall how long ago those innovations happened but never made it into mainstream. That would label current shells as dark age of tty :). I still cannot accept the fact that we use tty emulators.
For me PowerShell feels a bit more closer to that model, but it is still text based, no inline graphics or data structures output, and the syntax could surely be improved.