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

Nushell: Introduction to a new kind of shell

dataswamp.org

Post reply on HN
Print view View original

191–200 of 252 posts

Re: Nushell: Introduction to a new kind of shell

#191

Post by the__alchemist »

raydiatian wrote: post #176
the__alchemist wrote: post #169

Does anyone have an ELI5 for what this, BASH, ZSH, Powershell etc do? It seems it's a conflation of #1: A CLI. #2: A specialized programming language that mainly does file-system operations. Is there a compelling reason to use something like this (or Powershell's scripting system, from the comments here), vice Python or Rust's etc standard library filesystem tools? Context: I use Windows Terminal with embedded powers…

A shell is pretty much what you described. More accurately it’s a program for interacting with the operating system, and it usually ships with a scripting language, and Utility programs. Hence the conflation. If you’re using Windows Terminal, you’re using a sort of predecessor to Powershell (somebody please correct me on this), if you’re using terminal on Linux, you’re most likely using bash. Enter ps -p $$ at your L…

Appreciate those details! And as ripley said, Windows Terminal is a housing for other terminals like Powershell or various WSL OSes, but has tabs.

Re: Nushell: Introduction to a new kind of shell

#192

Post by parhamn »

SighMagi wrote: post #186
TheLocehiliosan wrote: post #183

Just was trying it. A couple minutes in, I discovered it doesn't support suspended jobs. :( seems like that would be a very basic feature. https://github.com/nushell/nushell/issues/1329 https://github.com/nushell/nushell/issues/1796 https://github.com/nushell/nushell/discussions/5239

In the past, I've toured these alternate, non-POSIX shells like Nushell. A lot of them (e.g. Powershell, Elvish) don't provide job control. I looked into how job control works and it's kind of a bother, so I see why they might have elided it. I wonder if multiplexing the terminal using tmux or screen is a good enough alternative the job control for many use-cases. You do lose state (i.e. environment variables, workin…

My data point: I prefer tmux/multiplexing over job control because the process hierarchy leads me to managing them better (I never accidentally quit tmux). Also I don't have to worry about std stream usage. I'm actually not sure of a case I'd care for job control.

Re: Nushell: Introduction to a new kind of shell

#193

Post by majkinetor »

nerdponx wrote: post #143
Pet_Ant wrote: post #90

Earlier quoted context omitted.

Honestly I’ve enjoyed working with PowerShell for scripts to work for all developers on my team regardless of what OS they are using.

I wanted to like Powershell, but it is missing some features that I think are essential. For example, apparently checking the return status of an arbitrary command is not trivial, and there's no equivalent of `-eu -o pipefail`. Yes, I know `-eu -o pipefail` is imperfect too, but it covers most common cases. I also struggled badly to stop it from mangling the output encoding of my applications (no, I don't want a godd…

pipefail is trvial: $ErrorActionPreference = STOP

Its even better then that as you can fail individual commands with their -ErrorAction argument.

BOM is not there any more.

Re: Nushell: Introduction to a new kind of shell

#194

Post by jborean93 »

nerdponx wrote: post #143
Pet_Ant wrote: post #90

Earlier quoted context omitted.

Honestly I’ve enjoyed working with PowerShell for scripts to work for all developers on my team regardless of what OS they are using.

I wanted to like Powershell, but it is missing some features that I think are essential. For example, apparently checking the return status of an arbitrary command is not trivial, and there's no equivalent of `-eu -o pipefail`. Yes, I know `-eu -o pipefail` is imperfect too, but it covers most common cases. I also struggled badly to stop it from mangling the output encoding of my applications (no, I don't want a godd…

The upcoming 7.3 release had PSNativeCommandErrorActionPreference which was an experimental feature to implement pipefail https://learn.microsoft.com/en-us/powershell/scripting/learn.... It is no longer experimental and will be part of the actual release. This allows you to set `$PSNativeCommandUseErrorActionPreference = $true` rather than rely on `$ErrorActionPreference = 'Stop'` which does more than just treat non-zero rcs as a failure which is nice.

Otherwise for older versions you can just do `my.exe; if ($lastexitcode) { "failure code here" }`. It's not nice but certainly not impossible to do.

Re: Nushell: Introduction to a new kind of shell

#195

Post by norman784 »

pie_flavor wrote: post #179
norman784 wrote: post #65

One issue I have with nushell is that on macOS they use the `Library/Application Support` path for the config instead of the `.config` making it awkward, their reason is that the former is the correct path of application data, while none of the other CLI apps I use do this, every other app just points to the `$HOME` dir or `.config` dir. I used it for a while but I switched back to zsh, maybe in the future when it ha…

it is the correct path for application data. Configs go in ~/.config on Linux, ~/Library/Application Support on Mac, and ~\AppData\Roaming on Windows; some other tools doing the wrong thing isn't a reason for nushell to do the wrong thing, and your preference for nushell doing the wrong thing shouldn't mean I have to suffer it. If you want it to be visible in your home dir, you can easily put a symlink there.

When you work on multiple OSes (mainly macOS and Linux), having your dot files normalized is IMHO the best experience, yes, I have symlinked, but if I need to setup a new mac (that does not happen often) then I could forgot about it and will take an extra step to setup, as I said that's just my preference.

Also I want to say that the ~/Library/Application Support directory only works good for desktop app, so it's easy to get rid of the configurations of an app that you want to uninstall (I use AppCleaner), but terminal apps you install most likely by a curl|bash or brew, so there's no point on using that directory IMHO, to me feels that the maintainers are not mac users so they don't care on improving that, for me, is a pain point.

But that does not take the merit of nushell, from all the other new ones (fish, oil, etc) I think is the one that I enjoyed the most.

Re: Nushell: Introduction to a new kind of shell

#196

Post by exyi »

naikrovek wrote: post #165
mustache_kimono wrote: post #83

Earlier quoted context omitted.

> I may never write a bash script again I wrote 2x 200 line-ish shell scripts recently, and it was simply terrible, and although I'm increasingly convinced we need a shell like abstraction, I can't believe `bash` is the best we can do. Really hope I find one of these alt shells that suits me. Not a fan of Python but xonsh looks really cool too.

Bash is not the best we can do, but it is definitely the best that most people agree on. I fear there will be no defacto bash replacement for many years.

What do you mean by "agree on"? We never agreed the programming language, which means ... that I can choose whatever I like.

Re: Nushell: Introduction to a new kind of shell

#197

Post by exyi »

bsdetector wrote: post #146

Having written a lot of shell scripts, the single greatest thing I've ever experienced is shell-friendly outputs. For example, consider if ls had a "--shell" option that output each entry as a single line of shell-quoted variables safe for eval: # cd /usr/share/dict # ls --shell words path="/usr/share/dict" file="words" user="root" group="root" size=985084 ... Then all sorts of things become easy. # eval $(ls --shell…

Many tools have some switch which will make them output JSON, which is easy to process if you have jq. For example `docker something --format='{{json .}}'`.

Re: Nushell: Introduction to a new kind of shell

#198

Post by SoftTalker »

bsdetector wrote: post #146

Having written a lot of shell scripts, the single greatest thing I've ever experienced is shell-friendly outputs. For example, consider if ls had a "--shell" option that output each entry as a single line of shell-quoted variables safe for eval: # cd /usr/share/dict # ls --shell words path="/usr/share/dict" file="words" user="root" group="root" size=985084 ... Then all sorts of things become easy. # eval $(ls --shell…

Part of it is knowing the tools. In this case, 'stat' is the command you probably want to get parsable details about a file, not more options to 'ls'. I often see convoluted shell scripts that could be a lot simpler with the use of more appropriate utilities.

Re: Nushell: Introduction to a new kind of shell

#199

Post by jborean93 »

Ygg2 wrote: post #86
alkonaut wrote: post #22

Earlier quoted context omitted.

What are the features that are done differently, or in other words, why would I choose Nushell over PowerShell?

Error messages are great, autocomplete works out of the box, and commands ArentCamelCaseMonstrocitiesOnlyMicrosoft --CouldLove.

> autocomplete works out of the box

> Error messages are great

Some improvements in pwsh would be nice here I agree but they have moved away from the more verbose error messages to a more concise view. I personally prefer if there was something like Python 3.11's new error message in PowerShell.

> autocomplete works out of the bo

Not sure what you mean, autocomplete works out of the box with PowerShell as well. It can even auto complete object properties and methods. You can also adjust the auto completion method to be like the shell you desire; i.e. bash/zsh modes.

> and commands ArentCamelCaseMonstrocitiesOnlyMicrosoft --CouldLove

Sure builtin ones are the `Verb-Noun` syntax but you don't need to follow this if you don't want. You can certainly use snake_case if that's your personal preference.

Re: Nushell: Introduction to a new kind of shell

#200

Post by exyi »

zokier wrote: post #188

Please correct me if I'm wrong, but doesn't nushell suffer from the same problem as powershell that all the nice fancy stuff works only for in-process commands and external programs are bit of a second-class citizens? To me interesting question is that is it even possible to build rich strucure-aware shell-like cli environment that would allow seamless integration of external polyglot programs in the same vein as uni…

nushell seems to have better way of parsing the string-only outputs of other commands.

https://www.nushell.sh/book/commands/parse.html

I don't know how to do a similar thing in powershell.

> To me interesting question is that is it even possible to build rich strucure-aware shell-like cli environment that would allow seamless integration of external polyglot programs...

Problem is that most of the classic Unix programs output in some messy format. It would be nice if we could agree that each command has --json flag (for example) which will make the output trivial to parse programmatically in any other advanced shell.

Post reply on HN