Nushell 0.86 | Hacker News Reader

Nushell 0.86

nushell.sh

95 pointskytazo45 comments

Nushell is quite nice. Tables are nice to work with and look at, and the cross-platform support is top notch. It feels like what Powershell would have been, had it been designed by people who have actually used a command-line before. The main issues I have are bugs. Most recently, I find that it can't properly handle files with square brackets in the name, which isn't really all that uncommon.

I wouldn't recommend it for day-to-day, production usage just yet, but definitely worth keeping an eye on if you're not a huge fan of the typical stringly-typed shells.

One advantage or Powershell though is that in it you can put something into the pipeline from anywhere in your code, even within imperative code like in the middle a loop, just by mentioning a bare value at nearly any spot. And traditional shells are the same way (though they only support byte streams output), where you can send stuff to stdout/err at any point.

But in nu, it's more like you're just dealing with collections as in most programming languages. If your collection isn't amenable to being generated by a simple expression like a map or fold, then you have to create a collection, prep the collection to be what you want it to be, then you return it.

In that sense it's really different from both Powershell and traditional shells, and more like just using a traditional programming language. So in Nu I miss being able to just "yield" a value from anywhere without staging into a temporary collection first.

> if your collection isn't amenable to being generated by a simple expression like a map or fold, then you have to create a collection, prep the collection to be what you want it to be, then you return it.

This release added the ability to "yield" values via a generator fashion. It's called `unfold`, but will be renamed to `generate` in the next release: https://www.nushell.sh/commands/docs/unfold.html.

Great news!

> It feels like what Powershell would have been, had it been designed by people who have actually used a command-line before.

It is designed by such people. Not sure why PowerShell tables and cross-platform support is not top notch \_(ツ)_/

Effort is salutable, but let's be realistic, Nushell is 10+ years from PowerShell.

Maybe in some areas, but in terms of day to day usage, I prefer nushell

> if you're not a huge fan of the typical stringly-typed shells.

What aspect of the other shells qualify them as 'stringly-typed'? Shells seem quite happy piping raw binary data, and there are commands that can deal with binary streams (like wc). The shell also doesn't seem to do anything with the data, unless specifically asked to do so (eval, backticks, etc). (genuinely ignorant and curious).

"Stringly typed" is usually used as a derogatory term for the alternative to strong typing, which often looks like manipulating raw strings when higher level code would have either better error handling or less boilerplate.

In this sense, dealing with raw bytes is worse.

There is no reason we can't use CLIs that provide higher level operations, but there's just not enough standardization.

I think they are refering to the fact that variables are always strings. You can write stuff like i=0;i=$(( i + 1 ) which looks like you are dealing with integers, but in reality, the shell only deals with strings.

That makes much more sense. I was wondering how shells are classified under type system theory.

You know those status bars in dwm and similar window managers? Those are usually generated from a pipeline outputting a line every few seconds or so.

To make it display something as trivial as the frequency of your CPU, the network speed, etc, you have to randomly parse some ad-hoc, program-dependent format that may be locale-dependent! If these could speak a proper language, one could just take the value of this field/object/element and be done with it.

Last time (about a month ago) I tried use it as my login shell, for a brief while. I really want to like it, but change is always difficult :)

The issues that I struck immediately where:

1. The macos `open` / nushell `open` conflict (various workarounds available, not quite sure what to do about it, the use of the macos command is very much in my muscle memory)

2. Some issue with tab completion being illogical, not choosing the shorter exact match as the first choice, tripping me up. This seems to be fixed now!

3. Setting up the env variables (PATH and other stuff), the syntax shown in the `config env` example is somewhat obtuse and I didn't really feel to actually learn all the possibilities to make it more nicer — so porting my .profile didn't seem like a fun endeavour. Also I realised keeping them in sync will be a bit difficult, if the syntax is wildly different.

I don't deal with _that_ much of structured data to actually make good use of nu's features — though I guess if I were to use it, it would inspire me to turn the data I do work with more amendable for nu.

Perhaps I should still try again :)

Friendly heads-up: it's considered unwise to use a non-unix compliant shell as your login shell. Rather configure your terminal emulator to use nu as its shell - or go through the effort of invoking it each time if you're not in a GUI.

>it's considered unwise to use a non-unix compliant shell as your login shell

I'll bite, why is this?

It's simple: there's too much code out there that assumes the login shell is Unix compliant. Remember that shells have been going out of their way to be Unix compliant for a very long time, rethinking the shell is a relatively new concept.

Quick question: what does “Unix compliant” mean in this context?

There are shells that are bash compatible, and shells that are sh compatible, and shells that work on posix systems, but I’m not sure what “Unix compliant” means.

I think you mean bash/sh compatible, as pretty much all code on the internet assumes that (a big reason why fish never really took off), and if you are putting things in .profile that expect bash (or sh) compatibility, and your shell doesn’t support that, it could do weird stuff.

sh is Unix compliant.

Ah, thats what I meant! The shell that `iterm2` logs in with, not `chsh`. I was a bit ambiguous there.

> The macos `open` / nushell `open` conflict

Hm, I see there's an issue and a recommendation to move nutshell open to nuopen - won't that get in the way of cross platform support? I would probably prefer to alias MacOS open (or xdg-open... Etc) to something like ”mope".

I'm guessing things like Emacs can be configured to point at an absolute path for open?

https://www.nushell.sh/book/configuration.html#macos-keeping...

https://github.com/nushell/nushell/issues/9220

You can bypass a Nushell command by prepending "^". To use MacOS open, this would be "^open cat.gif"

This tic drives me nuts when I hop between fish (which I use for two features, better tab completion and background jobs) and nu. With 0.86, it might just be for background jobs, which is something Nushell has avoided dealing with entirely. CTRL-Z and "bg" is just muscle memory for me, much like "open."

If you though writing a bash script can be addictive, wait till you write a nushell script !

The nushell language is clean and quite consistent. It is also much more powerful than bash/fish etc. Don't let the massive number of changes every minor version fool you -- nushell is ready to use. Probably not as a login shell but when you want an "all in one" replacement for the dozens of command line utilities in un*x.

Same. I've had to do tiny tweaks to my scripts when updating recently, but I'll take fixing those 2 lines over trying to maintain a script full of callouts to jq, weird quoting, carefully manually managed dictionaries, etc. Nushell is already amazing for devopsy usage.

Do you mind elaborating on your last point? I'm intrigued by nushell and I'm doing devopsy work, I'll give it a try now but I'd love to hear how you use it and learn from it!

It makes relying on "shell scripts" much easier. Almost entirely gets rid of explicit whitespace handling in variables. Has proper types, so doing some math is safer. Has built-in dictionary / array / tree value support. Has better error handling.

In practice that means gluing together many tools, especially json/yaml/network-related is easier and you have better safety around it all. You can have proper, reusable functions too.

Each script I rewrote from bash to nushell that basically strings together many AWS calls is ~2-3x shorter now and more readable.

That sounds promising. Did you use it in a team? If so, how well did they receive your avant garde shell language?

Also, have you tried other alternative shells like xonsh?

Except then you go to share something with others and have to convince people to install your esoteric shell first. It’s the same reason why I quickly abandoned fish - zsh with some fish niceties (auto-complete, etc.) gets me most of the way there, and in the odd case where I’m writing a script and use something zsh-specific, it’s not that hard to convert it to bash if necessary.

as someone else mentioned, the shell you use for interactive work and the language you use for scripting don't have to be the same thing. I use fish as my primary interactive shell( on linux) - but scripts for work stuff will still be bash. That said - nushell is now my primary shell for anything windows related. And I'm aiming to do any minor automation on windows in nu rather than .bat files.

Nushell is tremendously concise and elegant. This might win over your colleagues.

One has to be in a very specific mood to adopt a completely different tool as fundamental as a shell. The required investment and commitment is non-negligible. Even if you can convince people of the advantages, quality itself cannot get them magically over the hump in a day.

You have nushell "the language" and nushell "the shell". You can still use bash, fish, zsh for your day to day shell usage. They are proven, rock-solid and super stable. However, for the kinds of tasks that nushell excels -- gluing together programs, doing simple analysis of the output of text oriented programs etc. nushell can be a viable choice. Here I'm emphasing nushell "the language".

Every language was a niche language once when the user base was almost zero. So I guess it depends on your personality and organization -- are you an early adopter ? Or do you like waiting until the tool/language has established itself ?

I would argue that nushell lets you write powerful scripts like bash. But it can be better than bash because it offers powerful constructs, patterns and primitives. I think nushell is here to stay.

Why do you chose it instead of Perl or Python?

Python is often _too general purpose_. Everything you can do in Nushell you can do in Python except Nushell is just a bit more concise given it is specialized for being a shell language.

Nushell is cool also because it has inbuilt versions of `ls` etc. that output tabular data so it can do all kinds of fancy things with it.

How big of an initial time investment does it require? I.e. if I wanted to try it out on the side from time to time, can I just install and start using it, or does it take a week of learning and writing a configuration before I can properly use it?

I picked it up right around when this got posted https://news.ycombinator.com/item?id=37576303

More or less a month ago. As of speaking, I'm almost entirely familiar with the standard API, comfortable with the language enough to implement a wrapper around openai with built-in tooling and have a configuration which closely resembles my previous zsh interactive setup.

All and all, after a month of usage, I have no regrets apart from reasonable ones like investing time into what could be categorized as personal delight but the power that lies beneath your fingertips grows exponentially with all of this functionality available out of the box.

Its been a pleasure so far and witnessing its incredible pace makes it even more exciting with pleasant surprises from features introduces waiting in every second corner

Just install, and start using it on the side. It's quite intuitive. Maybe start with the `tutor` command, then go through the guide book: https://www.nushell.sh/book/

you can start using it right away and much of your muscle memory will still give decent results. I say much - since piping with > isn't a thing, but still, it doesn't take long to get used to using it.

I'd say if you spend a day experimenting with it, you're on your way to mastery.

One thing that's cool with Nushell is being able to wrap wrappers around existing commandline tools to get structured output (so a wrapper around `git branch` could give me structured data).

What I kind of want to go along with this is a (for the lack of a better word) query planner. Let me query structured data, but only pull in stuff as I need it, lazily. That way my structured data can be very detailed, but I only end up pulling the data I need on each iteration. That avoids pulling _everything_ from disk in structured wrappers.

There's probably a nice middle ground here but it's the one thing that's holding me back from writing a _lot_ of very detailed wrapper code for Nushell and the like.

> That avoids pulling _everything_ from disk in structured wrappers.

This is only really possible if the command you're wrapping allows filtering early on.

Something like kubernetes allowing to retreiving info about pods in certain states, instead of retrieving all pods and filtering afterwards.

Powershell puts a strong emphasis on this "filtering left" concept, that's why you have things like "gci" ("ls" equivalent), allowing you to pre-filter file types/names before a "where" clause, avoiding reading a lot of data.

Sorry, I wasn’t clear here. I’m not talking about limiting the number of entries, but about limiting the amount of data pulled per entry. Just like how a query planner in an RDBMS ends up only pulling relevant columns from disk.

I recently gave nushell a go for a few days, but I found that the structured data conveniences were not helpful all that often, at least compared to how often I was having to look up redirecting stderr or similar bash incompatibilities.

The biggest workflow-breaking issue for me was the lack of task backgrounding. I am almost constantly working in vim, backgrounding to test out changes, fg to resume editing. Opening a new tmux / zellij pane instead did not work well (I work on a smallish screen, new pane doesn't have the old pane's command history).

For background tasks, they recommend using pueue [0] with nushell.

It feels like Powershell's Start-Job a bit.

[0]: https://www.nushell.sh/book/background_task.html#using-nu-wi...

There is a learning curve and the standard library is not fully mature. Learning/reference resources are also not on par with bash, obviously.

> new pane doesn't have the old pane's command history

Sounds like a setup issue. You have to configure this manually for bash as well as nushell.

I also have the problem in bash, as the history is not written until the shell exits (having it write history command-for-command results in interleaving history with commands from other sessions, which doesn't work well for me).

But in bash, backgrounding works, so it's not an issue.

Any recent comparison between oils/ysh and nush?

https://www.oilshell.org/cross-ref.html?tag=YSH#YSH

Reply on news.ycombinator.com