My number-one wish for a NGS: Undo! Take, for example, rm. The hoops we have to jump through when accidentally rm'ing a file are ridiculous [1]. But in most cases (smallish, non-secret files), rm should be trivially undoable. Windows gets this right: By default, files are not deleted, but moved to trash. If there is not enough space in trash, Windows warns you. Or, if you really want to delete a file instead of movin…
NGS: Next Generation Unix Shell
91–100 of 204 posts
Re: NGS: Next Generation Unix Shell
#92Earlier quoted context omitted.
The point of issue 1 is that sometimes you don't know that the program will run for a long time. So a way to send a program into the background while it is already running, would be nice.
'Ctrl + z', 'bg' and 'fg' are for that.
Re: NGS: Next Generation Unix Shell
#93Earlier 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…
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.
Spaces in filenames are fine. The only strange thing is that, as it turns out, shells have this hidden easter-egg/anti-feature where you can actually leave out the quotes around filenames under certain, special edge-case scenarios. One of those is when the filename contains no ampersands, quotation marks, asterisks, dollar-signs, parentheses, backslashes, newlines, or, you guessed it, spaces! In fact, this special "no quote mode" also contains another special, embedded mode where you can still use those characters, but put backslashes before them! Since this layering of tricks leads to funky, confusing-looking commands, it's obviously much better to just stick with the regular mode of quoting everything.
Of course, the above is quite tongue-in-cheek, but its the mental-mode I specifically try to adopt: "occasionally, you might get away with leaving out the quotes"; compared to the seemingly more common "you need to add quotes in these cases".
Still, this doesn't eliminate the problem of single-quotes in filenames never going away! Whilst it only requires one character code to be escaped, it's still accomplished in a pretty funky way: "'" becomes "'\''"; we first close the string, then use a backslash to write a literal "'", then we start a new string ;)
Re: NGS: Next Generation Unix Shell
#941) Terminal UI improvements 2) Interactive shell UI improvements 3) Shell scripting language improvements 4) Userspace utility improvements
Tackling all of these together may well be possible, but it will likely limit the potential impact of any improvements you are able to make. IMO, it's easier to move the status quo with incremental improvements, not wholesale re-imaginings of how the entire text-based Unix user interface works.
Ultimately, the most dangerous thing to mess with is the language itself. The strongly-typed Python-lite described in the linked man pages is not going to replace sh/bash for simple scripts, sorry. For most shell-scripting needs that sort of thing is wayy overkill. Sure Bash is ugly, but ultimately there's no way to harmonize quick-and-dirty command-line compatibility with an elegant scripting language syntax.
An alternative approach here would just be to expand your thought process a bit and don't get too worked up about Bash itself. Pipelines and new tools can solve all your problems if you're willing to think about them in a different way. `jq` is an amazing pipe-friendly JSON munger that is now just as essential to my CLI toolbox as `awk` and `sed` ever were. It solves your structured-data and typing complaints without interfering with Bash one way or another.
Re: NGS: Next Generation Unix Shell
#95Earlier quoted context omitted.
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.
PowerShell actually does have data structures, and that's my favorite part of it. Pipe a directory listing as an object instead of text so you can access properties directly instead of parsing text!
Re: NGS: Next Generation Unix Shell
#96Earlier quoted context omitted.
> You're wrong on about three of those statements OK. Do you have any supporting arguments? "You're wrong" doesn't contribute anything. > note that the same hand wave It's not a "hand wave". Those things are easily verifiable facts. You're new here, you might want to read: https://news.ycombinator.com/newsguidelines.html
Not new. Javascript is not the most popular language, does not have the largest "package manager" (nor standard library, nor package library which is what I think you mean) and more importantly it does not have the most programmers specializing in the problem domain at hand -- shell functions. Moreover the referenced toolset doesn't even use Javascript ! You merely jumped in blind to promote your favorite tool. Also…
> does not have the largest package library, which is what I think you mean.
Yes, you've said that before. Do you have any supporting arguments?
I'm basing that opinion on:
1. JS is #1 on modulecount and #2 on libraries.io, the two places that track the size of package repositories.
2. JS continually coming up as the #1 or #2 most popular language on StackOverflow eg http://www.r-bloggers.com/the-most-popular-programming-langu...
Happy to talk about Perl once this becomes a dialog rather than you telling me I'm wrong without the courtesy of explaining why.
Re: NGS: Next Generation Unix Shell
#97My number-one wish for a NGS: Undo! Take, for example, rm. The hoops we have to jump through when accidentally rm'ing a file are ridiculous [1]. But in most cases (smallish, non-secret files), rm should be trivially undoable. Windows gets this right: By default, files are not deleted, but moved to trash. If there is not enough space in trash, Windows warns you. Or, if you really want to delete a file instead of movin…
I bet you could solve this with ZFS and automatic snapshot creation for each new command. Want to undo the past N commands? Roll back to a previous snapshot!
This idea falls over if the amount of data you create (which the shell can't know in advance) is too big to contain in a snapshot. All that would be possible is an automatic notification that the operations in XYZ directory are no longer undoable due to its size.
Re: NGS: Next Generation Unix Shell
#98This is a blue-sky project. Completely new, with no legacy dependencies.
AND YET THE DEVELOPER CHOSE TO WRITE IT IN C. WHY FOR THE LOVE OF GOD, WHY?
Could someone explain this to me? Is it developer hubris, believing in one's own infallibility that a single exploitable stack frame or buffer overflow couldn't possibly happen "on my watch"?
If you need a native binary, your options are endless. Rust, Go, Haskell, hell, even C++ with smart pointers and runtime bounds-checking would be a step up.
Please, someone educate me on why people still choose to write inevitably-vulnerable software in 2016, when there is no legacy reason to do so.
Re: NGS: Next Generation Unix Shell
#99Earlier quoted context omitted.
wc is not a builtin. In that example we're not in front of a bash word splitting issue. I agree with you that shell scripting has caveats one need to learn. As does Perl, C, PHP, Ruby, Node, Go, Java and what not. I don't feel a big change is needed to handle spaces in shell scripts, my scripts handle them and I enjoy writing them. Maybe you know of minor tweaks for bash,zsh or any common shell which could be useful…
Once again, you're getting too hung up on my dumb little example, which I spent exactly 0 seconds thinking about. It's the general problem that's interesting (and annoying), the 'command1 | command2' general case. If you want a difficult example, then take a more real-world example: e.g. the workflow of a 'find [some stuff] |grep [some other stuff]' is one to consider. That's where horrid workarounds like -print0 and…
Re: NGS: Next Generation Unix Shell
#100Earlier quoted context omitted.
'Ctrl + z', 'bg' and 'fg' are for that.
Except, now you are back to my original problem -- the output of the program will continue to spew all over my terminal.
When there is a "surprisingly slow" command, then just press the shortcut for a new screen session.
Will get alerted in the status bar when the slow command finishes.
Output of each command will be in it's own screen session (not mixed).
That Ctrl + z response was no for issue1, but for the wishes of the second sentence of @hibbelig.