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

311–320 of 411 posts

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

#311

Post by godtoldmetodoit »

j1elo wrote: post #295
vips7L wrote: post #248

Earlier quoted context omitted.

In powershell you would use built ins. To download json over rest you would use Invoke-RestMethod or irm. To convert json to objects you would use ConvertFrom-Json. To select properties from objects you would use Select-Object or select. Here is a concrete example that I wrote for the rustlings install script: https://github.com/rust-lang/rustlings/blob/main/install.ps1... Note that I used Invoke-WebRequest instead o…

And then I guess the shell itself has mechanisms to easily attach or register new commandlets, to allow for easily add custom object processing? I really like the consistency that those commands have: ConvertFrom- . No built in converter for the format you need? I'm just speculating here, but I guess you just need to implement this or that Interface and there you go.

You can define your own function and use it in your pipeline yes. You can have your function take pipeline input just like the built in cmdlets.

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

#312

Post by steveklabnik »

pjmlp wrote: post #301
steveklabnik wrote: post #278

Earlier quoted context omitted.

The Rust compiler is roughly “parse -> AST -> HIR -> MIR -> LLVM IR -> binary.” I forget exactly where editions are erased (and I’m on my phone so it’s hard to check), but for sure it’s gone by the time MIR exists, which is where things like the borrow checker operates. Edition based changes only affect the very front end of the compiler, basically. This is a necessary requirement of how editions work. For example, i…

When Rust editions reach about 5 in the wild, feel free to prove me wrong by mixing binary crates compiled with two Rust compilers, mixing three editions into the same executable. You can also unpolitelly tell me how it will be any different from /std=language for any practical purposes.

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, and you keep not listening. It’s FUD at this point.

It is different because those are frozen, editions are not (though in practice editions other than 2015 will rarely change). They make no guarantees about interop, and my understanding is that it might work, but isn’t guaranteed. If you have sources to the contrary I’d love to see them!

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

#313

Post by ofiryanai »

On top of the nice approach to structured output with pipelines, the "cross-OS first" approach is amazing! Very cool to use a modern shell that can fit both Windows and Unix by design (and not through WSL), hell I'm going to try to introduce it to my small company as a standard tool. Hope it's not in a too immature stage, however it looks very shining and promising considering the enthusiast contributors community. I'm in

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

#314

Post by pjmlp »

steveklabnik wrote: post #312
pjmlp wrote: post #301

Earlier quoted context omitted.

When Rust editions reach about 5 in the wild, feel free to prove me wrong by mixing binary crates compiled with two Rust compilers, mixing three editions into the same executable. You can also unpolitelly tell me how it will be any different from /std=language for any practical purposes.

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.

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

#315

Post by vips7L »

j1elo wrote: post #295
vips7L wrote: post #248

Earlier quoted context omitted.

In powershell you would use built ins. To download json over rest you would use Invoke-RestMethod or irm. To convert json to objects you would use ConvertFrom-Json. To select properties from objects you would use Select-Object or select. Here is a concrete example that I wrote for the rustlings install script: https://github.com/rust-lang/rustlings/blob/main/install.ps1... Note that I used Invoke-WebRequest instead o…

And then I guess the shell itself has mechanisms to easily attach or register new commandlets, to allow for easily add custom object processing? I really like the consistency that those commands have: ConvertFrom- . No built in converter for the format you need? I'm just speculating here, but I guess you just need to implement this or that Interface and there you go.

Yes you can write your own cmdlets in either C# or powershell that you can install via modules [0]

You can also just write a function in your profile.

[0] https://docs.microsoft.com/en-us/powershell/scripting/develo...

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

#316

Post by aru »

xpe wrote: post #290
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"

I see the value proposition of nushell. I'm wondering if I should also try fish. May I ask if you switched to fish from zsh? What motivated your change? Background: I invested some time not too long ago to read zsh docs in detail and customize my own configuration (e.g. instead of using oh-my-zsh). Since then, I've been quite happy with zsh. That said, I'm also open to switching to fish and/or nushell based on recomm…

I didn’t switch from zsh, but from bash, to fish, primarily because bash was occasionally a bit clunky to use, and there were a lot of things that could be optimized in a modern environment. I settled on fish because it suited what I was looking for: an ergonomic shell that worked well out-of-the-box. Paired with strong community support, clean scripting syntax, and a wide ecosystem, it makes for a really enjoyable shell experience. I haven’t tried zsh, so I can’t compare the two.

I’m happy with fish, and I don’t see much benefit to switching to nu. nu is exceptionally good at one thing: working with data, but lacks features in other areas (auto-completion, scripting, etc.). With time, I can see these features being implemented, but I think they’ll be re-inventing the wheel in a lot of areas that other shells are already good at.

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

#317

Post by 13of40 »

rjzzleep wrote: post #178
pjc50 wrote: post #114

Earlier quoted context omitted.

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…

Everything you say is accurate, but it doesn't really relate to his claim for the reasoning behind the decisions behind Powershell. That's what I was referring to when I asked for a more detailed elaboration.

I worked in Windows Server on admin tools in the late 90s and 2000s, and watched the whole thing happen. I heard it summed up like that from Ballmer himself. I don't know what your alternative idea is - you think Microsoft was jealous of Linux and spent a hundred million dollars making a new shell just so they could feel proud?

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

#318

Post by zozbot234 »

pdpi wrote: post #88
kamray23 wrote: post #36

Earlier quoted context omitted.

Why do you not? No memory leaks, no security issues stemming from such. No random crashes from memory misuse, no issues debugging the issues that exist. It's like a higher level language but lower. You get to do things your way, except when your way is fundamentally unsafe. The code is then easier to debug as it actually describes what's happening and issues are mostly algorithmic, while the application gets a massiv…

Rust is perfectly happy to leak memory. Leaks are not considered unsafe. There was actually a bit of a reckoning around the 1.0 release where people widely assumed the language wouldn’t leak, and leaks were proven to be safe behaviour.

Unintentional leaks are rare in Rust, the main issue is around reference counting loops not being cleaned up automatically. Future versions of Rust might even offer some support for unleakable 'relevant types' (the dual to the existing 'affine types' where leaks are not considered incorrect) for better support of very advanced, type-directed resource/state management.

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

#319

Post by sudhirj »

hibbelig wrote: post #299
j1elo wrote: post #288

Earlier quoted context omitted.

I agree... and any well written script will have a shebang that specifies the shell that shluld run it, anyway. For me, personally, I love having homogeneus systems put in place. In this case it means not having to switch my mind between in and for modes. Helps me avoid mistakes, having to keep less context up here. But it's always interesting to read about other people's way of working.

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