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

71–80 of 204 posts

Re: NGS: Next Generation Unix Shell

#71

Post by nailer »

tacos wrote: post #55
nailer wrote: post #46

Earlier quoted context omitted.

Probably because JavaScript is the worlds most popular programming language, it's portable, has the largest package manager, supports the shell's non blocking requirement, and the current version (ES6) has a better stdlib than previous versions.

You're wrong on about three of those statements, but note that the same hand wave could have been made for Perl ten years ago. That would've been a poor choice then for the same reason Javascript is a poor choice now.

> 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

Re: NGS: Next Generation Unix Shell

#72

Post by joosters »

txutxu wrote: post #63
joosters wrote: post #52

Earlier quoted context omitted.

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…

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 -z have to come in, but the simple 'find|grep' works fine up until a file has a space in it.

As I said, there's no simple fix, even for the re-organised form of 'grep [some other stuff] `find [some stuff]` because the shell can't tell the difference between a filename and just a stream of text in the output of one program.

Re: NGS: Next Generation Unix Shell

#73

Post by js2 »

heydonovan wrote: post #9

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

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.

Re: NGS: Next Generation Unix Shell

#74

Post by tacos »

nailer wrote: post #71
tacos wrote: post #55

Earlier quoted context omitted.

You're wrong on about three of those statements, but note that the same hand wave could have been made for Perl ten years ago. That would've been a poor choice then for the same reason Javascript is a poor choice now.

> 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 if you want to play HN-by-the-book then you should refute my argument why Javascript shell scripting in 2016 from a cold start is somehow better than Perl shell scripting in 2000 given its lead back then.

Re: NGS: Next Generation Unix Shell

#75

Post by CaptSpify »

txutxu wrote: post #45
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.

Not sure on why this comment got down-voted. If it's because I did not explain how to do that, there is howto do it: http://mywiki.wooledge.org/BashFAQ/004 If it's because the comment on the given example... $ touch file1 $ ls -l | wc -l 1 $ touch "file 2" $ ls -l | wc -l 2 ... (?) If we were talking about "new lines in file names", or "dashes at the beginning of file names", or code injection through file names, the…

I'm guessing it was down-voted because you keep missing the point. Yes, there are work-arounds for this scenario, but the overhead in remembering the work-arounds is the problem. He's not saying you can't do it, he's saying the problem is that you have to change your setup for edge-cases, which are actually fairly common.

Re: NGS: Next Generation Unix Shell

#76

Post by txutxu »

joosters wrote: post #72
txutxu wrote: post #63

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

If I could need to combine a find|grep right now (this is, if the directory recursion and filters of grep by itself, weren't enough, which maybe a corner case too...) I could do it like this:

    while IFS= read -rd '' file; do
      echo "do whatever with: $file"
      grep whatever -- "$file"
    done
It's like natural language if you do it daily.

Will handle not only spaces, but also

new

lines

on

file

names.

Have a nice day.

Re: NGS: Next Generation Unix Shell

#78

Post by CaptSpify »

maho wrote: post #58

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…

Although I kind of agree with you, I'll play the devil's-advocate: If you actually care about the file, it should have a backup that you can restore from anyway. And, depending on the file, that backup should be source-control.

Re: NGS: Next Generation Unix Shell

#79

Post by tomsmeding »

txutxu wrote: post #51
dfcowell wrote: post #42

Earlier quoted context omitted.

That there are worse things that exist is no reason not to pluck the low hanging fruit. I see this attitude on HN a lot. Spaces are probably the 80 in the 80/20 rule here. Why not address them?

Please give a single example in shell about spaces, that has not been already addressed. From where do your get that rule?

It's the pareto principle. In this case he means "20% of the problems account for 80% of the trouble" -- albeit somwhat strangely worded.

Re: NGS: Next Generation Unix Shell

#80

Post by zbjornson »

pjmlp wrote: post #40
cm3 wrote: post #34

Earlier quoted context omitted.

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.

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!
Post reply on HN