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

GitHub – nushell/nushell: A new type of shell

github.com

Post reply on HN
Print view View original

321–330 of 411 posts

Re: GitHub – nushell/nushell: A new type of shell

#321

Post by arupy »

augstein wrote: post #271
aru wrote: post #264

I use this in combination with fish shell and it's been working really well. I can just switch over to `nu` when the task merits; no need to replace my current shell. I can also just run a one-off line like this. nu -c "ls | where size > 10b"

How does it compare to fish shell (especially fish’s great autocompletion), e.g. why are you not switching completely?

nu is still in its infancy, and currently lacks critical features of other shells, which is why I haven’t switched completely.

As for the future, perhaps a bit brazen, but I’m confident that other shells will introduce the core feature of nu in the near future to stay competitive. I can see fish having a “||” operator and rewrites of a few gnu functions to achieve what nu does natively.

Re: GitHub – nushell/nushell: A new type of shell

#323

Post by gnubison »

mavhc wrote: post #242
j1elo wrote: post #234

Earlier quoted context omitted.

Shellcheck is nowadays a must for writing decent shell scripts. it is like a centralized knowledge base of all those brilliant minds that did the sanity checking for you in the old days :)

It boggles my mind that people use a language where x = 0 doesn't work and x=$y is a security flaw

> x = 0 doesn't work

Maybe it's just me, but I love how the assignment syntax can be used just for a single command: 'MANPAGER=cat man' is a lot nicer than '(MANPAGER = cat; man)'.

> and x=$y is a security flaw

When is variable assignment a security flaw?

Re: GitHub – nushell/nushell: A new type of shell

#324

Post by Apofis »

maccard wrote: post #133
j1elo wrote: post #107

Thinking this is so cool! I was wondering if seriously buying into an alternate shell like this would be worth it in the long run. Would really love to read from people who use(d) an alternative shell, both success and failure stories. I cannot shake from my head the idea that buying into a non-standard shell will only work for personal projects in one's own workstation, but it won't fly too far for company work beca…

I tried fish for a while. The differing syntax between fish and bash for fundamental things mean I was running all my scripts through bash anyway, and if I wanted to share them/use them elsewhere in the company it had to be bash, so I swapped back to bash.

I used fishshell for years, and the bottom line ended up being that it created enough mental overhead to be a burden because it diverged from the UNIX norm too much. Sort of like the colemak keyboard layout, sounds great in theory, in practice, not so much.

Re: GitHub – nushell/nushell: A new type of shell

#325

Post by johnfn »

korse wrote: post #322

I don't get these sorts of efforts. 'Let's make something complex appear intuitive by adding more complexity'. I really respect the work that has gone into this project, but no thanks.

But that can work. Just look at Google: massively complex product and problem, but sure appears pretty simple to the layman - I just type some words into the box and hit enter!

Re: GitHub – nushell/nushell: A new type of shell

#326

Post by pornel »

pjmlp wrote: post #314
steveklabnik wrote: post #312

Earlier quoted context omitted.

Again, the ABI issue has nothing to do with editions. You can already build a binary today with three editions (though I forget if 2021 has any actual changes implemented yet) in the same executable. Part of the reason I said what I said is that every time we have this conversation you say you want to see how it plays out in practice, and we have shown you how multi-edition projects work, and how you can try it today…

Which is basically the same thing as /std=language, when applied to different translation units.

There is the similarity that the editions don't really matter for ABI, but otherwise editions are substantially different from the std switch.

C/C++ std switches freeze the entire language and disable newer features. Editions don't. Rust 2015 edition isn't an old version of Rust. It's the latest version of Rust, except it allows `async` as an identifier.

Editions don't really have an equivalent in C, but they're closer to being like trigraphs than the std compilation switch.

Re: GitHub – nushell/nushell: A new type of shell

#327

Post by OJFord »

sudhirj wrote: post #319
hibbelig wrote: post #299

Earlier quoted context omitted.

If you want to make the systems homogeneous, then you need homogeneous teams, too. Maybe some team members prefer fish, others prefer zsh, still others prefer bash. Your suggestion means that everyone has to use the same shell for their command line. I find that it is better to allow each team member to have their own working environment: different (command line) shell, different editors/IDEs, different keyboard shor…

Yup. There are more shells than there are IDEs, keyboard switch types, keyboard layouts, and operating systems. Shell ideological wars get just as bad as emacs/vim and linux/Mac. Use whatever you want, but company IP is shbang'd to bash.

> shbang'd to bash.

Good.

Better: #!/bin/sh

Best: #!/bin/sh and also not assuming bash anyway!

Re: GitHub – nushell/nushell: A new type of shell

#328

Post by bawolff »

rnestler wrote: post #112
bawolff wrote: post #67

Earlier quoted context omitted.

Were you not able to before? ls | grep foo | sort is hardly something people normally read the man page for.

This isn't the way I'd sort ls output by date or whatever field. I'd use `ls -l --sort=date` which I guess is what the GP meant with having every tool do their own sorting by field. In nushell one can just do `ls | sort-by size`

Ah, fair enough. I misunderstood the parent.

Re: GitHub – nushell/nushell: A new type of shell

#329

Post by bobthebuilders »

OJFord wrote: post #327
sudhirj wrote: post #319

Earlier quoted context omitted.

Yup. There are more shells than there are IDEs, keyboard switch types, keyboard layouts, and operating systems. Shell ideological wars get just as bad as emacs/vim and linux/Mac. Use whatever you want, but company IP is shbang'd to bash.

> shbang'd to bash. Good. Better: #!/bin/sh Best: #!/bin/sh and also not assuming bash anyway!

I wouldn't say putting a sh shebang and assuming bash is better. With a bash shebang at least you're honest about it.

Re: GitHub – nushell/nushell: A new type of shell

#330

Post by sudhirj »

OJFord wrote: post #327
sudhirj wrote: post #319

Earlier quoted context omitted.

Yup. There are more shells than there are IDEs, keyboard switch types, keyboard layouts, and operating systems. Shell ideological wars get just as bad as emacs/vim and linux/Mac. Use whatever you want, but company IP is shbang'd to bash.

> shbang'd to bash. Good. Better: #!/bin/sh Best: #!/bin/sh and also not assuming bash anyway!

If we're distributing software, maybe? Personally we control the hardware, so we know what we're running, but yeah, for libraries or packages this makes sense.
Post reply on HN