Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

NGS: Next Generation Unix Shell

github.com

Post reply on HN
Print view View original

61–70 of 204 posts

Re: NGS: Next Generation Unix Shell

#61

Post by regularfry »

gravypod wrote: post #50

What is this intended on fixing? I don't think the solution to anything is to make the shell more user-friendly. The only solution is to make the graphical user-interface more user friendly and feature full. The only time it should be acceptable to be forced to use a shell, in my opinion, is if you are swapping out your desktop environment. Until that happens, Windows and OS X will rule the desktop and PC market. I'm…

> The only solution is to make the graphical user-interface more user friendly and feature full.

There's only one feature that matters here, really: composability. Provide an environment in which I can compose simple tools into complicated workflows I can fling data through, and we might have a winner.

> The only time it should be acceptable to be forced to use a shell, in my opinion, is if you are swapping out your desktop environment.

Why should that be true? It's not at all obvious to me. I have yet to see a GUI that lets you express something like `grep '^127' /etc/hosts | awk '{print $2}'` in any sane fashion. The closest you get is something like LabView, but that's counted out here because it's a general purpose(ish) language.

If your response is that this type of task is artificially skewed towards a text-based, shell-centred environment, then you don't have the type of problem that this shell is intended to fix.

Re: NGS: Next Generation Unix Shell

#62

Post by ilyash »

lottin wrote: post #26

Just 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.

Sorry, by outdated I meant not a good fit for today's problems.

Re: NGS: Next Generation Unix Shell

#63

Post by txutxu »

joosters wrote: post #52
txutxu wrote: post #32

Earlier quoted context omitted.

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.

You miss my point. Of course, for every example I give, it's possible to build a workaround to handle the spaces. My point is, it's the very fact that you need a workaround that makes it so irritating. 'command1 | command2' just works in most circumstances, so it's frustrating that it falls apart when a filename with a space appears. And it technically is a shell issue, insomuch as the shell is dividing up the ARGV f…

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 in general purpose of files with spaces in the name? don't hesitate to open them a bug, maybe we even get a fix.

But don't send them this example, and insist on it, because the conversation is over:

    $ touch a_file
    $ ls | wc
          1       1       7
    $ rm a_file
    $ touch "a file"
    $ ls | wc
          1       2       7
Equivalent input, with/without spaces and expected output.

The 2 is a word count, and we did pass two words, I don't expect a 1 there, _that_ could be a bug.

Re: NGS: Next Generation Unix Shell

#64

Post by isaaaaah »

My 2 tinfoil hats: If they can't have your kernel, they try to get your shell...

To me, i really do not see the points listed to be missing. For instance my shell script for remote execution on multiple hosts needs somewhere around ten lines of code and a peer list. I would never outsource this to an external entity. Especially today.

Re: NGS: Next Generation Unix Shell

#66

Post by ilyash »

voaie wrote: post #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 rat…

I see now. The parenthesis don't feel like a convenient syntax.

Re: NGS: Next Generation Unix Shell

#67

Post by ilyash »

amelius wrote: post #29

I 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.

I encourage you and others to open issues or make a pull request with updated README

Re: NGS: Next Generation Unix Shell

#68

Post by gravypod »

regularfry wrote: post #61
gravypod wrote: post #50

What is this intended on fixing? I don't think the solution to anything is to make the shell more user-friendly. The only solution is to make the graphical user-interface more user friendly and feature full. The only time it should be acceptable to be forced to use a shell, in my opinion, is if you are swapping out your desktop environment. Until that happens, Windows and OS X will rule the desktop and PC market. I'm…

> The only solution is to make the graphical user-interface more user friendly and feature full. There's only one feature that matters here, really: composability. Provide an environment in which I can compose simple tools into complicated workflows I can fling data through, and we might have a winner. > The only time it should be acceptable to be forced to use a shell, in my opinion, is if you are swapping out your…

> I have yet to see a GUI that lets you express something like `grep '^127' /etc/hosts | awk '{print $2}'` in any sane fashion.

I think we are in a very interesting time in computer science history where he have a huge slew of technology that solves a large set of problems that no one wants to exploit.

I could easily see an "assistant" type window being created in a desktop UI. Since we don't need a "windows" key in the linux world, I'd assume that would be used.

My ideal system would allow me to go into a text document, click the windows key, and say "grab me every line from /etc/hosts that starts with 127"

When the job would be completed, I'd see a check mark or something and the result would either be pasted to my cursor or, if my cursor wasn't in a text box, copied into my clipboard or something.

While this might sound like magical science fiction, it isn't. Neural networks, NLP, and HCI fields are doing some amazing things. The only problem is these are harder to implement then a simple terminal and pipe.

That is a sane way of interacting with a system that is user friendly.

In the same way, it could also handle other complex things. IE: "open my browser", "open the Internet", "list all the things connecting to the Internet", "open the last document I was editing in my text editor"

This is doable, albeit extremely difficult to implement well, but doable.

Re: NGS: Next Generation Unix Shell

#70

Post by voaie »

ilyash wrote: post #66
voaie wrote: post #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 rat…

I see now. The parenthesis don't feel like a convenient syntax.

Scheme could be a good language (for fans?) if it is not used interactively.
Post reply on HN