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 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).
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.
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.
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?
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.
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.
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?
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.
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).
[+] [-] DixieDev|2 years ago|reply
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.
[+] [-] sixbrx|2 years ago|reply
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.
[+] [-] majkinetor|2 years ago|reply
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.
[+] [-] goku12|2 years ago|reply
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).
[+] [-] scoopr|2 years ago|reply
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 :)
[+] [-] zamalek|2 years ago|reply
[+] [-] e12e|2 years ago|reply
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
[+] [-] sidkshatriya|2 years ago|reply
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.
[+] [-] viraptor|2 years ago|reply
[+] [-] sgarland|2 years ago|reply
[+] [-] tambourine_man|2 years ago|reply
[+] [-] sundarurfriend|2 years ago|reply
[+] [-] rtpg|2 years ago|reply
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.
[+] [-] jiehong|2 years ago|reply
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.
[+] [-] n8henrie|2 years ago|reply
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).
[+] [-] jiehong|2 years ago|reply
It feels like Powershell's Start-Job a bit.
[0]: https://www.nushell.sh/book/background_task.html#using-nu-wi...
[+] [-] ctenb|2 years ago|reply
> 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.
[+] [-] e12e|2 years ago|reply
https://www.oilshell.org/cross-ref.html?tag=YSH#YSH