Live data from Hacker News

GitHub – nushell/nushell: A new type of shell

github.com

71–80 of 411 posts

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

#71
post #45

Very promising project that I hope it will take off and succeed. I recently switched to zsh with the addition of oh-my-zsh and I am happy how it has features like auto completion and command validation of some sort, but this could take it to the next level. I am just afraid to change to it and be disappointed about some incompatibility issues or bugs / crashes. I will observe and wait until it's quite popular to hop…

Try fish shell. It has auto completion by default and is easy to configure with web interface "fish_config", no need to rely on some community repo like oh-my-zsh. There can be bugs if you set it as default shell but i just append "fish" at the end of my .bashrc :)

It's so interesting - it seems that fish is getting more and more popular lately.

I tried it ~7 years ago and thought it was severely lacking, so I just stuck with zsh and have never really had a reason to look back.

Maybe I'll check out fish again at some point - what features does it have that drew you to it?

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

#72
Looks pretty cool.

Anecdotally, I found switching shell to be more of a challenge than expected - I’ve been using (oh-my-)zsh for years and decided to try fish, but all the little differences were too annoying for me to get used to - I guess you build up a lot of “muscle memory”! That said, I probably just use the same commands most of the time. If you were doing more advanced stuff maybe it makes more sense to invest the time

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

#74
post #43

Earlier quoted context omitted.

PowerShell from Microsoft is looking too alien on Unix. Just looking at the syntax I already feel uncomfortable. It's hard for me to criticize it because I haven't used it, but it looks like it was designed by a committee and overdesigned. I.e. it wasn't created from the need, like someone at Microsoft wanted to automate his work and created PS to solve his problem. It looks like some boss decided: "They have shells,…

> They have shells, so we should have it also The thought process was more like "You can either hire a dude to do it by mouse in MMC or you can get someone with a masters in CS to do it in DCOM. We need a middle ground." Source: was in the room

Can you elaborate?

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

#75

Earlier quoted context omitted.

> This feels extremely like PowerShell, from all the examples, and even cites "draws inspiration from projects like PowerShell", so "a new type of shell" feels very disingenuous unless it has additional novel properties that aren't evident just from these. There's HN-style nitpicking, and then there's this.

I'm sorry, but I'm not actually sure what you're trying to express here. My initial interpretation is that this is a level beyond typical nitpicking, but I'm not sure how that follows?

"A new type of shell" is a bit of marketing text to express the fact that this shell doesn't follow in the footsteps of most other shells (bash, zsh, fish, etc) in terms of treating things as blobs of text (which allows for a number of innovations). The fact that the author even states that it's partially inspired by Powershell demonstrates that he's aware of the similarities (and has in fact cribbed many ideas from it).

Calling his marketing line "disingenuous" comes across as very petty nitpicking that adds nothing of value to the discussion.

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

#76
post #65

Earlier quoted context omitted.

I think Cargo doubling as both build tool and package manager is a big factor here. The combination of Cargo + crates.io makes it very easy to write some Rust code and make it available to anyone with Cargo on their system. Either by `cargo install nu` to build it from sources on crates.io or `cargo install` inside the git repo to build my own customized version. No more waiting for distro packagers to keep up. Putti…

This is insanity and hubris. "It's so easy!" yes if you have the language and tools de jour installed and up to date. I want none of that. It was node and npm. Then go. Now Rust and cargo. Oh, I forgot ruby. And all this needs to be up to date or things break. (And if you do update them then things you are actively using will break.) I don't need more tamagochis, in fact the less I have, the better. What happened to…

Why don't you download the native binaries then?

Rust isn't an interpreted language, you only need the rust toolchain if you want to build from source.

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

#77
post #57

I wonder if this could be accomplished in a more general way with a fourth standard file descriptor for structured data. stdjson basically.

A pipe only conveys stdout. You could redirect 4>&1 1>/dev/null, but you'd have to rewrite all tools to generate both stdout and stdjson anyway.

> You could redirect 4>&1 1>/dev/null

For anyone confused by this, 1 is the output to stdout, and 4 is being redirected to where 1 goes, which is stdout. Unrelated to that, 1 (what’s actually being output to stout by the application) is being redirected to /dev/null.

The order of operations matters. If 1 was redirected to /dev/null first, then 4 would also end up in /dev/null. As it stands now, that doesn’t happen.

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

#78
post #54

Earlier quoted context omitted.

I’m sorry to say this but this is a very uninformed comment with way too many biases without any backing. > I.e. it wasn't created from the need, like someone at Microsoft wanted to automate his work and created PS to solve his problem Interestingly enough, it is used for automating Windows configuration. Re last paragraph: UNIX commands are random letters that are like that due to historical reasons — if you don’t k…

Yes, I haven't used PowerShell. And I agree that my comment is uninformed. It's just that I feel uncomfortable even looking at the PS syntax. Maybe it's idiosyncratic. Maybe I've spent too many years in Unix shell.

I've used it and I can relate to the comment. Maybe your assumptions are off in there, but I think the main point you were trying to make is that it's complicated. It's so complicated that you really need a repl to be able to work with it efficiently. It's a bit like how programming Java is simple if you do it in Idea or back then in eclipse, but in a pure editor it's impossible to remember all the boilerplate.

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

#79
post #54

Earlier quoted context omitted.

I’m sorry to say this but this is a very uninformed comment with way too many biases without any backing. > I.e. it wasn't created from the need, like someone at Microsoft wanted to automate his work and created PS to solve his problem Interestingly enough, it is used for automating Windows configuration. Re last paragraph: UNIX commands are random letters that are like that due to historical reasons — if you don’t k…

Yes, I haven't used PowerShell. And I agree that my comment is uninformed. It's just that I feel uncomfortable even looking at the PS syntax. Maybe it's idiosyncratic. Maybe I've spent too many years in Unix shell.

Sorry for calling you out on it, I often write opinion-pieces without much backing as well :)

I was initially very biased against PS as well, but then had to learn it and I found the design quite genius. At a time I even tried to use it as a daily driver on linux but my muscle memory is UNIXy, and there are a few edge cases that are harder in PS than in bash so I had to revert back. But we should strive to keep an open mind even about Microsoft technology :)

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

#80
post #57

Earlier quoted context omitted.

A pipe only conveys stdout. You could redirect 4>&1 1>/dev/null, but you'd have to rewrite all tools to generate both stdout and stdjson anyway.

> You could redirect 4>&1 1>/dev/null For anyone confused by this, 1 is the output to stdout, and 4 is being redirected to where 1 goes, which is stdout. Unrelated to that, 1 (what’s actually being output to stout by the application) is being redirected to /dev/null. The order of operations matters. If 1 was redirected to /dev/null first, then 4 would also end up in /dev/null. As it stands now, that doesn’t happen.

Good one. I did look it up before I posted, too. I’m never 100% sure.
Post reply on HN