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

111–120 of 411 posts

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

#111

Post by rincebrain »

kstenerud wrote: post #75
rincebrain wrote: post #58

Earlier quoted context omitted.

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…

Ah, I see. Thank you for explaining.

The part that bothered me was not that they described something that shared some concepts with PowerShell as "a new kind", but that I did not see any illustration of entirely novel features in the examples that followed. As a sibling comment remarked, they feel I'm quite mistaken, and there are very positive distinctions illustrated in the examples, but I took a look at them again, and it's still not clear to me what they mean.

I think I don't see why it's unreasonable for something which advertises cross-platform support to be compared to common shells on all those platforms, not just originally-*ix ones? That is, I think it's totally reasonable for you to think the tagline is justified solely by the differences in those shells, even if I disagree, but I don't see why you think it's unreasonable for me to hold this view?

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

#112

Post by rnestler »

bawolff wrote: post #67
sime2009 wrote: post #55

I played with it recently. The interactive part is limited at the moment, but I really like the idea of having operations like sorting and filtering separate from the tools which produce the data. Having these things consistent and available everywhere is a huge cognitive win. I can finally sort and filter `ls` output without having to read the man page. :) "Querying" data feels a lot like SQL in that respect.

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`

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

#113

Post by kaba0 »

wokwokwok wrote: post #90
kaba0 wrote: 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…

> So while I am not particularly fond of Microsoft, powershell is better than bash (though frankly, what isn’t?) in every conceivable way. There are fair criticisms to be made of bash...but this isn’t a fair comment either; I use power shell a lot; I’ve written hundreds or thousands of lines of powershell glue for scripts and devops pipelines and all kinds of things. It’s not very good. It is one of those things that…

I didn’t mean that PS is the ideal shell, it has plenty of warts (I did mention the Verb-Noun thing), and bash’s syntax does have a good subset — namely piping, redirects to a certain degree. But variable substitution, not having proper math support, everything is text are terrible and they do come up with the arguably rare, more complex commands. Also, having a convention that has quite a few edge cases where it doesn’t work good may still be better than not having any. And the application not creating good cli is not shell-specific at all —- the linux world has it better because a good cli is prioritized. Even though git is often touted as having a terrible interface.

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

#114

Post by pjc50 »

rjzzleep wrote: post #74
13of40 wrote: post #43

Earlier quoted context omitted.

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

Not OP, but: MMC = Microsoft Management Console, the collection of "snap in" GUI config tools for all the advanced features beyond Control Panel.

MMC can control remote computers, but I believe only one at a time? Unless it's something through Group Policy.

Now, the APIs exist to do all this remotely (DCOM), but good luck discovering what they are! And the minimum level of program you'd need to call them would be a C# project.

So, Microsoft knew that UNIX systems had an API that was interactive, scriptable, discoverable, and composable, all the things which CMD and MMC and DCOM aren't. So they decided to build one. And make it object-orientated. It's actually pretty good for the administration use-case, but for more general work it feels weird. And it doesn't interact with text files anywhere near as good as shell does.

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

#115

Post by dgrunwald »

im3w1l wrote: post #83
oarsinsync wrote: post #77

Earlier quoted context omitted.

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

So you are supposed to read it from right to left? "First take 1 and throw it away. Next put 4 in 1." Is that how it works?

No, it's from left to right. It's basically just syntax for a series of dup2() calls.

"4>&1 1>/dev/null" means:

streams[4] = streams[1]; streams[1] = open("/dev/null");

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

#117

Post by pjmlp »

aldanor wrote: post #89
chx wrote: post #65

Earlier quoted context omitted.

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…

Ruby requires an interpreter at runtime. JavaScript too. Rust produces standalone binaries. So no, "things don't break" and you only compile things once. // I can't care less about deb or rpm files so don't try to force that down my throat.

It is Gentoo all over again.

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

#118

Post by the_biot »

bennyp101 wrote: post #91
the_biot wrote: post #69

Nushell missed the one feature that every Unix shell has: if it doesn't recognize the first word as a built-in command, look it up and run it as an executable. It's crucial, and nushell is missing out on an ecosystem of random shell commands to complement it as a result. This, of course, is what makes the Unix shell so great: the many little programs able to work together via pipelines. This makes nushell an interpre…

Its the 2nd paragraph "If a command is unknown, the command will shell-out and execute it (using cmd on Windows or bash on Linux and macOS), correctly passing through stdin, stdout, and stderr, so things like your daily git workflows and even vim will work just fine."

Argh, how did I miss this. The ^ is just for overriding built-ins with external executables. Apologies!

Clearly I hadn't tried nushell -- this feature I thought missing was a big no for me. I have now, and this is definitely worth a try. Thanks all!

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

#119

Post by pjmlp »

29athrowaway wrote: post #26
firefly284 wrote: post #11

Earlier quoted context omitted.

Why is everything written in rust nowadays? Apart from the safety it provides.

Backwards compatibility can be a heavy burden for a programming language. C++ could be a much simpler, ergonomic language by eliminating features and idioms that are no longer convenient to use. Achieving mastery in C++ requires a lot of work. C++ projects require a coding standard. The decision space you have when working in C++ is much larger than when working with Rust due to the proliferation of language idioms.…

I just hope that Rust with 40 years of backwards compatibility feels better than C++ today.

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

#120

Post by j1elo »

qmmmur wrote: post #101
j1elo wrote: post #93

Earlier quoted context omitted.

100% agree. I find it very funny, but in a sarcastic and totally wrong way, when a project's README has an Install section that reads: Run "cargo install myProject" I know Rust, so Cargo is not alien to me. But come on, you know that your install instructions are a bit shitty. Please, choose a target distro, then test your instructions in a clean Docker container. THEN you can sit down knowing you wrote proper guidan…

Hold on, do you not see the insane contradiction of not wanting to rely on having cargo installed but requiring something is deployable and tested in a docker container? What?!

No, you misunderstood. I meant that if you're going to document a block of command-line instructions, you should first make sure those commands work as-is in a clean system.

A very easy way to do this (for me anyways) is using a Docker container. I use this method to test all of my documented commands. But there are other ways, of course, like using a clean VM. Regardless, just test the commands without assuming the customized state of your own workstation!

The point is that if I follow the hypothetical instructions of running "cargo install something", the result will probably be "cargo: command not found". When you test this in a clean system and find this error message, this places on you the burden of depending on Cargo, so the least you should do is to make sure "cargo" will work for the user who is reading your docs. At a minimum, you should link to somewhere that explains how to install Cargo.

tldr: you should make sure your instructions work as-is from a clean installation of your intended distro(s), regardless of how you prefer to do so.

Post reply on HN