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.
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.
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.
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.
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).
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.
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.
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 :)
I'll bite, why is this?
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.
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...
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."
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.
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.
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
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.
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.
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).
It feels like Powershell's Start-Job a bit.
[0]: https://www.nushell.sh/book/background_task.html#using-nu-wi...
> 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.
But in bash, backgrounding works, so it's not an issue.