NGS: Next Generation Unix Shell • Hacker News Board

Re: NGS: Next Generation Unix Shell

#171

Post by joosters » Thu, Apr 21, 2016, 11:57 PM UTC

kps wrote: post #114

joosters wrote: post #106

Earlier quoted context omitted.

I'm struggling to find any information on this command (it's not an easy name to search for!) Do you have any links you could share please?

Apologies, I forgot to include a link: The toolkit is now at https://github.com/att/ast since AT&T laid off the group a couple years ago. About half the package consists of evolutions of traditional Unix commands. The parts I use regularly are ksh and tw. tw ('tree walk') is sort of a 'find --exec' replacement with a C-like selector syntax. It's a bit verbose, so for interactive use I generally set up project-specifi…

Thanks, this looks interesting!

Re: NGS: Next Generation Unix Shell

#172

Post by GunboatDiplomat » Thu, Apr 21, 2016, 11:58 PM UTC

oblio wrote: post #170

GunboatDiplomat wrote: post #168

Earlier quoted context omitted.

I have to disagree with the idea that everything should be standardized. What's the point of different distros if everything is just going to be the same? Might as well just tell everyone, "Ok, we're all going to use CentOS."

If you want shipping, you want standards. They should be creative in the UI and system administration tools (maybe not even for those tooks), otherwise we can't build anything on top of them. There's no real use for 3000 distributions anyway. Most of them can't even support the software they include properly. And most of them duplicate so much effort it's not even funny anymore (rpm vs deb, yum vs apt, etc.). Standar…

There should be a standard withing the organization (we use CentOS for everything internally), and for systems which need to inter-operate, for example, the internet.

There does not need to be a standard for shells, for network script syntax, etc.

You say they duplicate effort, which is true, but you assume the effort being expended would simply be redirected where you think it's needed. If you kill off half of distros, you probably just cause the people working on them to go away, not switch to one of the remaining distros.

Re: NGS: Next Generation Unix Shell

#173

Post by Symbiote » Fri, Apr 22, 2016, 1:16 AM UTC

CJefferson wrote: post #154

Symbiote wrote: post #137

Earlier quoted context omitted.

With Zsh: > touch {dark\ red,green,light\ blue}{cheese,fish\ fingers,fruit} > ls -1 *(cheese|fish)*([1,5]) dark redcheese dark redfish fingers greencheese greenfish fingers light bluecheese > for i in *(cheese|fish)*([1,5]) ... Since that's shell globbing, it can cope with any spaces, newlines etc.

Wow, that is quite impressive, I might have to look into this more. The advantage of using head is I only have to learn it once, to get the first n of lines or files, but it might be worth learning. Thanks.

I know 25% of the special Zsh syntax, and know of a further 25% of what exists.

I read the whole manpage some years ago, and noted down what seemed useful. I use "man zshexpn" when I forget the syntax for things like this.

Re: NGS: Next Generation Unix Shell

#174

Post by js2 » Fri, Apr 22, 2016, 3:29 AM UTC

gervase wrote: post #124

js2 wrote: post #73

Earlier quoted context omitted.

older SysAdmins I hope you aren't referring to their age, in which case consider using a different adjective: experienced, seasoned, wiser, etc. Your colleagues probably don't want to install fish shell for reasons besides how old they are.

Or, if you disagree with their opinion: hidebound, closeminded, timorous, etc. I think the parent was going for something indicating disagreement, so it seems unlikely that your "positive" adjectives are what they were looking for.

I've been on both sides of the equation, having disagreed with sysadmins about their enforcing of a particular login shell, and having been a sysadmin myself. Not installing fish shell on production systems ("across the farm") is something I'd chalk up to wisdom, not a lack of open-mindedness. I was subtly suggesting that in my choice of positive adjectives.

Re: NGS: Next Generation Unix Shell

#175

Post by codygman » Fri, Apr 22, 2016, 4:58 AM UTC

leephillips wrote: post #145

vox_mollis wrote: post #139

Earlier quoted context omitted.

No, because they are both legacy software. I understand momentum in codebases - that's why I'm reserving my vitriol for fresh bluesky projects like this one. As for exploitability, privilege escalation and shellcode injection is still very much a thing, internet-facing or not.

Git started in 2005. I'm sure Torvalds knew all about buffer overflows then, but decided to use C. You seem to think this is a crazy decision.

> Git started in 2005. I'm sure Torvalds knew all about buffer overflows then, but decided to use C. You seem to think this is a crazy decision.

Well is it? Will it be if Linus isn't maintaining it?

Re: NGS: Next Generation Unix Shell

#176

Post by wicket » Fri, Apr 22, 2016, 5:31 AM UTC

blakeyrat wrote: post #129

wicket wrote: post #111

Earlier quoted context omitted.

On UNIX, the "API" is basically that everything is a file and programs are written to handle text streams. After all these years, the shell is still perfect for this. It sounds like you want create a new language and shell in order to have something similar to Windows PowerShell which interacts .NET objects using its API. This does not fit into the Unix "API" described above. This isn't a "Next Generation UNIX Shell"…

That's great, but how much data do you work with, day-to-day, that is best represented as text streams? For me, the answer is "virtually none". Heck, most of the stuff I work with, day-to-day, can't even be represented meaningfully in a text stream . (Editing video, for example.)

For me, the answer is "plenty", but that's neither here or there. Everyone has their own use case and I daren't say yours isn't valid.

Video editing tends to done in applications, of course that's not to say video data can't already be piped. I once set up a screencast using gstreamer to convert /dev/video to an HTML 5 compatible video format which I then redirected to a named pipe which could then be opened from a HTML file page in a web browser. The UNIX shell is already very powerful. You haven't stated what it is you want to do with video editing that is either difficult or not currently possible but would be possible with this new shell, so I'm not sure that I really understand the point that you are trying to make.

There is nothing wrong with creating an alternative shell. I can see the need for something like this. PowerShell for example works very well. My main gripe with this project is that the author has named it "Next generation UNIX shell" which suggests that it is intended to be a replacement rather than an alternative. In my humble opinion, it tosses the simplicity out of the window that makes UNIX, UNIX.

To quote Dennis Ritchie, "UNIX is simple. It just takes a genius to understand its simplicity." I'm no genius, but I get it.

Re: NGS: Next Generation Unix Shell

#177

Post by dmytrish » Fri, Apr 22, 2016, 5:41 AM UTC

Bjartr wrote: post #105

voidz wrote: post #13

Earlier quoted context omitted.

Thanks to tmux, I don't have a problem with multiple interactive commands and their outputs. If I need to do something new, I open another shell on a new pane. Not that other solutions aren't welcome, but this works for me. If I don't want output at all, the &>/dev/null output redirection works, or file descriptor redirection, for which zsh has useful methods. Spaces in filenames are easily solved by quoting filename…

One of the problems tmux and friends don't solve that a "smarter" underlying system might add is the ability to make the choice to detach a process or redirect its output after it's already begun running. For example, I specifically have had on many occasions started something and then later wished I'd previously started screen. While, "gain the knowledge to better configure your environment to start" is a valid resp…

"Detach during running" is a problem solved from the beginning of shells: just suspend a foreground command with C-z and type `bg` to wake it up in the background.

Output redirection seems to be a valid point, though.

Re: NGS: Next Generation Unix Shell

#178

Post by dmytrish » Fri, Apr 22, 2016, 5:55 AM UTC

spc476 wrote: post #165

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…

The QNX shell could easily do remote execution. I worked at a company in the mid-90s (porting Unix software to QNX). My machine had a modem on it, and my boss (the owner of the company) would use it from his computer to dial out---all he had to do was reference the modem device on my computer at his command line. In fact, you could run a program on a local machine referencing a file on a second machine, pipe the outp…

This is a quite neat example, but it looks like the QNX shell mixed several concerns about how do you connect to these machines, how do you secure the communication, etc.

    $ ssh @2 "cat /path/to/large/file" | ssh @3 "/bin/grep 'foo'" | ssh @4 "cat >/tmp/output"

is rather clunky, but separates those concerns well.

Re: NGS: Next Generation Unix Shell

#179

Post by wicket » Fri, Apr 22, 2016, 6:00 AM UTC

Tarean wrote: post #142

wicket wrote: post #111

Earlier quoted context omitted.

On UNIX, the "API" is basically that everything is a file and programs are written to handle text streams. After all these years, the shell is still perfect for this. It sounds like you want create a new language and shell in order to have something similar to Windows PowerShell which interacts .NET objects using its API. This does not fit into the Unix "API" described above. This isn't a "Next Generation UNIX Shell"…

It is more that unix shells are built on piping and piping is systematically broken in unix shells. It just becomes extremely obvious after using for powershell for any time which doesn't require most of the work to scrap and rewrite ouput to make it compatible withan other program. Doing piping well is extremely hard and basically requires that all commands give metadata about their arguments but doing it better wou…

I'm not really sure what you mean when you say "piping is systematically broken". It sounds like you might be trying do something that isn't really meant for piping. The general idea behind UNIX programming is that projects should be broken down into small, simple programs that rather than overly complex monolithic programs[1][2].

Re: NGS: Next Generation Unix Shell

#180

Post by regularfry » Fri, Apr 22, 2016, 6:15 AM UTC

gravypod wrote: post #68

regularfry wrote: post #61

Earlier quoted context omitted.

> 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…

I think you might have missed the subtlety here. The interesting bit isn't `grep '^127' /etc/hosts`. It's `|`. There are umpteen ways to launch individual applications, but nobody's yet come up with quite such a flexible, simple and expressive way of getting them to communicate as streams of text.