These bugs have existed for so many years I've 100% given up on Nushell. I recommend you don't subject yourself to software that is this level of unreliable and unbothered about being so unreliable.
(There's a lot of missing/misimplemented features, but the above is so severe they're not even worth mentioning.)
If you're ever forced to use Windows, just install nushell. The speedup is wild, and along with it comes many nice quality of life features.
Nushell is good on the Unixes as well, but the defaults there are less annoying. I regularly revert to bash because there's just some thing I've memorized in bash, and bash doesn't make me want to scream.
Note that this is just my perspective on it as an interactive shell. I've never used it for scripting.
I've tried the stock Windows shell and utilities. `ls` is noticeably slow in directories with like 15 subdirectories. That's not acceptable. Even the terminal emulator is so slow pasting 30 characters takes several frames. That's not too annoying, but I might replace it with Wezterm or something.
The stock Windows terminal experience is awful. Windows has improved markedly recently with `winget`, so maybe they'll get around to fixing the speed sometime, too.
Powershell is slow to start (~1-8 seconds on my PCs, even without a profile.ps1) and it performs pretty poorly in general (eg. processing texts and pipelines) compared to other options -- even Python by a wide margin.
I love Powershell and I wish MSFT would put a concerted effort into optimizing its performance.
Powershell itself can be noticably slow to even start. Waiting a minute or two to hit a prompt is just annoying. Yes this only happens if you run Windows on a spinning disk but it's a shell. It's shouldn't require an SSD to run.
There is one company who decides what PowerShell is, and they are not known for stability in many areas.
Just as easily as Aero switched to Metro, syntax in PowerShell will do what they want, despite impacts to your legacy scripting.
The POSIX shell, on the other hand, is a POSIX standard controlled by the Austin group. The classic adaptation is the Debian Dash shell, which is both tiny and fast, and changes are very, very slow.
Dash can be linked with libedit and used as an interactive shell. Everyone should do so, before learning non-standard extensions in Korn, Bash, Zsh, et al.
Shells are a matter of taste to a great extent. These are different envelopes of features, stability, and portability.
Each releases breaks something, usually, and it’s been like that for a few years (like the default config file that was generated is no longer parsed after an upgrade, or a function was renamed, etc.)
I guess they are trying to go this way with their standard lib somehow.
Which is pretty much readable though. The only issue is Pascal vs C syntax. As a fan of the former, I admit that the latter is more advanced: it stacks better. E.g. consider
if (test -f junk) rm junk
against
if test -f junk; then rm junk; fi
The former “avoids semicolons that Bourne requires in odd places, and the syntax characters better set off the active parts of the command.” [1]
The semicolon is required only when not using new lines to split the command words, as in
sleep 60; do_the_thing_that_needs_a_minute_wait
It's not necessarily required in the for loop either, I tend to prefer the more compact method of putting the "do" on the same line as the for. It can be written as
for i in {1..10}
do
print $1
done
Having "done" be the signifier of the "the for loop context ends here" is 3 characters more than "}" or ")" or whatever else. "done" is more color coming off the screen with syntax-highlighting, and can be typed in two keypresses with a "d" and a "tab" in any editor from the last 30 years. It just seems like a very very inconsequential nitpick. At least Nushell doesn't pull a Python and just have "invisible space" be the end of the for-loop.
One line conditionals are doable as well in the shell.
test -f junk && junk
or
[[ -f junk ]] && junk
You can even just use [ -f junk ] if double brackets is giving the yuck.
I have never seen the second version. Apparently it's there since bash 3.00 (2004). Maybe took inspiration from zsh who also has (or a common ancestor ?)
Imagine though, if we shell-heads came over to Windows and started writing an entirely new shell to replace Powershell because we didn't want to learn Powershell. It's just so utterly bizarre to me. I guess people like what they like, and that's cool, but wanting to rip out a 40+ year old scripting environment and command line shell because it doesn't look like goddamn Ruby or Clojure or Rust or whatever is just intolerable.
I have always struggled a bit with shell replacements. I use zsh but only because of oh-my-zsh. Apart from that I always thought of shell scripts as a necessary evil for interoperability. Today you can usually expect a linux system to have bash or at least sh. That is why I do shell scripting. Nushell is usally not preinstalled on a system and so I cannot expect it.
If I want to do real scripting/programming I use python or another dedicated programming language. I don't really know what the value of Nushell is for me. Maybe the plugin system is amazing but at the moment I miss nothing in my zsh.
I really would like a new shell that wasn't based on a poorly designed programming language from the 1960s[1][2]
However, I need to know sh/bash well because they're the tools installed by default; in any "well-established" organization, getting approval to install a new shell will range from "12 to 24 months" to "impossible". And without that, I'm not going to put in the effort to learn a new tool that is only useful some of the time and requires massive context switching.
That's what I mean. A new shell would need to blow me away with some amazing must have interactive feature. The scripting part is, at least for me, not really relevant. If I can install software on the target I will install a proper language and if not then it will be bash or sh anyways, even though they properly suck.
The "killer app" is that it's easy to string together multiple commands and have them work more reliably than shells that rely on plaintext. In other words, it's something in-between running individual commands and writing full scripts. I've not used Nushell before, but I'm very familiar with PowerShell which is similar, and it's ridiculously easy to manipulate and explore your file system with confidence that you don't have to rely on hacky and hard to read regex and similar suboptimal solutions.
Python is good for general-purpose scripting, which does cover most of the tasks, but it’s still too bureaucratic when it comes to OS primitives. And when a small script at hand is tightly related to some OS thing anyway, it’s not a disservice to write it in shell.
Python's main distinction from a shell scripting language is that external program invocations are not first-class citizen. Also no easy ways to feed/read the subprocess's std io.
Coming from the shell, one of the most annoying things about Python is working with files. In the shell I can read and write to files on the filesystem with basically no friction and no extra infrastructure. Just a "cat" command or a <, >, or >>. The ease at which input and output can just get tossed around in the shell is the biggest thing I end up missing when I graduate up to any "real" language.
I remember when I first learned how to work with files in Python and thought "Damn, y'all live like this?"
Maybe I need to get into nushell more but my feeling is that if it's a simple problem it the benefit will be negligible and if it is too complicated for that I will probably write a python script.
That was my feeling as well. Why learn some not-used-anywhere-else scripting language when we have bash/zsh with battle tested scripts and snippets? Also, nushell will probably break everything that expects a normal bash/zsh/fish.
I’d probably rather use xonsh as I do more complex scripts in Python anyways.
That is how I felt with Zsh, even though Zsh scripting is a step up from Bash. But with Nushell there is a huge space of scripts I now prefer to write in it.
We all know the dueling aphorisms of "if it ain't broke, don't fix it" versus "no risk, no reward", so I'll just say this: there is a middle way. I keep a whole lotta Zsh and Bash scripts. But for work on systems I control, Nushell is a boon. I use it for interactive work and add scripts when I see a need.
Nushell commands are really great, so great that they are even better than the standard library of some languages. However, the language itself isn't very intuitive to learn.
I wish Nushell and Python/TypeScript have a baby one day.
well if you want a python/shell hybrid there's always xonsh (https://xon.sh/). Really great in particular for people like me who are bash-challenged. I do like Nushell too but I also always had problems remembering the actual language.
I really wanted to get into nushell but i found reedline to be very limiting in a few specific ways esp around keybindings that blocked me from moving to it
I’ve created a small utility script at work that automates some routine tasks and nicely formats the collected data in a table, and I can say that Nushell is an amazing tool.
this is very weird timing, I literally just installed nushell this morning lol. I like it so far but that may just be the novelty effect. I gotta find a syntax file for vim, tho, because moving over my bash aliases and trying to visually parse the config file after 10 lines or so is making me go cross-eyed.
caveat up front: I see that the point here is to talk about a nice, good thing for people to use that is useful, and I don't think that's a bad thing. I am also always looking for ways to upgrade, and I also agree that in a modern context with modern knowledge, we can do better.
However, regarding the posix skepticism - I think OP has missed (or just not mentioned) the actual thing that keeps bash/zsh from being unseated.
Industrial standards are a good thing just because they’re standards. They’re right that a redesign would be superior in terms of raw design, but this is only useful if it’s adopted widely enough so that you don’t have to context switch between two fundamental systems. I spin up a new VM somewhere and it's going to have bash. I use a tool and I expect it to follow a particular convention - having to figure out which I'm reaching for adds an amount of friction that would make most work untenable.
I like zsh but I also want something better. Type safety and robust completions would make me very happy, but if we're going to make the switch we have to do it as an industry - with a set of agreed upon interfaces and standards that are carefully thought out and built on consensus. I don't know if that's possible given the massive complexity of the state of affairs but that's what it would take.
A nice coincidence to read this; I was just telling some friends the following (lightly edited):
Nushell is amazing and a total pleasure to use. I cannot yet discern any limit to how much thought has been put into it.
I’m stunned in a good way. I’m writing shell scripts without any pain — actually I much prefer them to Python! With the language-server integration – I use Zed, but I'm sure they exist in VS Code and others too – I can see errors in scripts as I write them! (Including typos in pathnames! Amazing.)
I have to admit Nushell didn’t become my daily driver right away; it took a few years for me to switch fully. I don't know exactly why, but it probably had to do with its lack of POSIX compatibility. I now see this as a necessary break for Nushell to pursue its vision.
About expectations: some people will be delighted immediately and get hooked, but not all. We're all busy and adopting a new tool can feel like a leap of faith. For me, it has been worth it. Nushell has felt like planting a garden that gives back way more than you put into it.
I wrote up a quick gist [1] that shows how nice the experience is to write a new command (i.e. function) in Nushell.
If you haven't tried PowerShell I strongly recommend you do. It is really well designed and the way objects are piped between commands is brilliant and very powerful. Combined with property filters you can do SQL like queries. The ConvertTo-JSON lets you export the output of any command to JSON which is amazingly useful. As an example you can dump the entire Active Directory (Assuming you have permissions) by
To clarify, in PowerShell there is a difference between text between single quotes (e.g. '$test') and double quotes (e.g. "$test"). Single quote strings are literal strings, so whatever text is contained within them is reproduced as written. Double quote strings are expandable strings, which means that certain text inside the string is evaluated before it is returned. If you have double quotes in a literal string, you'll see double quotes within that string, and the same should be true for ampersands.
I started using nushell around April 2024. While it is much better than other shell languages, the lack of proper types is painful.
Shell languages make sense if you believe in the Unix philosophy. For me, the problem with the Unix philosophy is the endless serialization and deserialization as well as lack of proper error handling. So nushell for me is a good answer to an ill-posed question.
The approach I have been taking is a single binary with a billion subcommands and aliasing these.
I currently have two of these in Rust, one in Swift. I tried going all Rust but integrating with certain aspects of macOS is just so much simpler in Swift.
Like the recent push to make CLI development suck less (e.g. argument parsing used to be painful but is solved now) has made developing CLI tools a lot less painful.
serialization/deserialization will always be needed unless you got all your programs working with the same ABI. it's just that in nushell's case you aren't serialize to human readable text.
endless serialization and deserialization is what makes me hate Bash and love PowerShell which solves this issue by piping full objects between commands and the ConvertTo-JSON command.
i've never used nushell, but i've always felt that people have been sleeping on PowerShell.
yes, it was _originally_ only for Windows, but PowerShell 6+ uses .NET Core, which is OS independent. this means that a few helper functions like GeneratePassword[0] are gone, but it's _mostly_ at parity with .NET.
the Verb-Noun structure can be confusing at first, but once you know the approved verbs[1], you can usually guess your way through command discovery, which is not something i can say for most POSIX tools (useradd and adduser do different things!!)
it's also object oriented by design, with default aliases like ?[2] and %[3], querying structured data is a breeze.
- want to check a CSV? Import-CSV[4].
- want to call a REST/SOAP endpoint? Invoke-RestMethod[5] has you covered.
- DNS queries? Resolve-DnsName[6]
as it's built on top of .NET, you get the whole CLR[7] at your fingertips! you can make a TCP client[8] in PowerShell, or even just write C# directly in your terminal[9] and execute it the same way.
such a flexible and useful language, even if it is a little slow and owned by micro$oft. but it _is_ open source[10]!
As a prior contributor to PowerShell, I think part of this obscurity reason is how they neglected their community. This was evident in their merged PR history only containing commits from Microsoft developers.
I use nushell now, and its community is fantastic. It may face breaking changes every so often, but it has a much faster execution speed and more features if you're not tied into the .NET ecosystem.
Powershell is pretty great, though I am constantly bit by issues with filenames having [ or ] in them and end up having to pass -LiteralPath to everything, which is frustrating and a constant source of bugs in any other scripts that do not do that.
Something I came to appreciate is that the 50MB binary is really battery included. You will be able to deal with JSON, XML, SQLite DBs, HTTP requests and more. I personally do not need anything else.
Now, no matter how much you get excited about it, do not write too much production code with it as it still change and break often between releases.
Do not let the "shell" in the name fool you. Nu is a full on programming language. I've spent more time with it than pretty much any other lang and if I have to describe it in one sentence, I'd say: It's the most beautiful combination of the ease of Python, strictness and ergonomics of Rust and of course shell capabilities of Bash.
It's really its own kind of thing. It's definitely not just another shell.
I've written very impressive and very complex software in nu. I fully expect it to take off very fast as it nears a stable v1.0. I can't imagine going back to anything else.
The example FOR loop in BASH is missing a trick to make it easier to read:
for i in {1..10}; do
echo $i
done
(Though I prefer using printf than echo as it's more capable and POSIX compliant)
I write far too much stuff in BASH, but for me it's just not worth moving to using a different shell due to its ubiquity. There's also the question of "will this still run easily in 20 years". Of course, BASH is a nightmare for bugs and foot-guns unless you make a point of defensive coding (e.g. surround variables with double-quotes and using Shellcheck to point out common errors).
By the way, the article goes on to mention the large number of options to "ls". Don't try to parse the output of "ls" in scripts as there's better ways to do things: https://mywiki.wooledge.org/ParsingLs
Last I looked, Nushell
- error handling is neglected in the basic design: <https://github.com/nushell/nushell/issues/10633>, <https://github.com/nushell/nushell/issues/10856>, <https://github.com/nushell/nushell/issues/8615>, <https://github.com/nushell/nushell/issues/6617>
- control-C interrupts its internals with obviously-wrong error: <https://github.com/nushell/nushell/issues/8828>, is mishandled in other ways <https://github.com/nushell/nushell/issues/8206>
These bugs have existed for so many years I've 100% given up on Nushell. I recommend you don't subject yourself to software that is this level of unreliable and unbothered about being so unreliable.
(There's a lot of missing/misimplemented features, but the above is so severe they're not even worth mentioning.)
FWIW it looks like this addresses the pipe error behavior: https://github.com/nushell/nushell/pull/16449
If you're ever forced to use Windows, just install nushell. The speedup is wild, and along with it comes many nice quality of life features.
Nushell is good on the Unixes as well, but the defaults there are less annoying. I regularly revert to bash because there's just some thing I've memorized in bash, and bash doesn't make me want to scream.
Note that this is just my perspective on it as an interactive shell. I've never used it for scripting.
Windows already has a very good shell called PowerShell.
I've tried the stock Windows shell and utilities. `ls` is noticeably slow in directories with like 15 subdirectories. That's not acceptable. Even the terminal emulator is so slow pasting 30 characters takes several frames. That's not too annoying, but I might replace it with Wezterm or something.
The stock Windows terminal experience is awful. Windows has improved markedly recently with `winget`, so maybe they'll get around to fixing the speed sometime, too.
Windows terminal and Powershell are 2 distinct programs
Powershell is slow to start (~1-8 seconds on my PCs, even without a profile.ps1) and it performs pretty poorly in general (eg. processing texts and pipelines) compared to other options -- even Python by a wide margin.
I love Powershell and I wish MSFT would put a concerted effort into optimizing its performance.
Powershell itself can be noticably slow to even start. Waiting a minute or two to hit a prompt is just annoying. Yes this only happens if you run Windows on a spinning disk but it's a shell. It's shouldn't require an SSD to run.
> Waiting a minute or two to hit a prompt is just annoying.
I've never experienced startup times anything close to a minute. Is your computer very old?
There is one company who decides what PowerShell is, and they are not known for stability in many areas.
Just as easily as Aero switched to Metro, syntax in PowerShell will do what they want, despite impacts to your legacy scripting.
The POSIX shell, on the other hand, is a POSIX standard controlled by the Austin group. The classic adaptation is the Debian Dash shell, which is both tiny and fast, and changes are very, very slow.
Dash can be linked with libedit and used as an interactive shell. Everyone should do so, before learning non-standard extensions in Korn, Bash, Zsh, et al.
Shells are a matter of taste to a great extent. These are different envelopes of features, stability, and portability.
Powershell syntax is much much more consistent than Korn, bash, zsh, etc.
For now, Aero to Metro awaits you.
May you enjoy the trip, my friend. You deserve it.
Aero to Metro is completely irrelevant to powershell.
Still not super stable.
Each releases breaks something, usually, and it’s been like that for a few years (like the default config file that was generated is no longer parsed after an upgrade, or a function was renamed, etc.)
I guess they are trying to go this way with their standard lib somehow.
Is
for i in 1..10 {
}really all that more readable than
for i in {1..10}; do
doneLike, am I taking crazy pills? They're basically exactly the same!
Bash is an advanced beast. In Bourne, it was
Which is pretty much readable though. The only issue is Pascal vs C syntax. As a fan of the former, I admit that the latter is more advanced: it stacks better. E.g. consider against The former “avoids semicolons that Bourne requires in odd places, and the syntax characters better set off the active parts of the command.” [1]1: Rc—The Plan 9 Shell https://9p.io/sys/doc/rc.html
The semicolon is required only when not using new lines to split the command words, as in
sleep 60; do_the_thing_that_needs_a_minute_wait
It's not necessarily required in the for loop either, I tend to prefer the more compact method of putting the "do" on the same line as the for. It can be written as
for i in {1..10}
do
doneHaving "done" be the signifier of the "the for loop context ends here" is 3 characters more than "}" or ")" or whatever else. "done" is more color coming off the screen with syntax-highlighting, and can be typed in two keypresses with a "d" and a "tab" in any editor from the last 30 years. It just seems like a very very inconsequential nitpick. At least Nushell doesn't pull a Python and just have "invisible space" be the end of the for-loop.
One line conditionals are doable as well in the shell.
test -f junk && junk
or
[[ -f junk ]] && junk
You can even just use [ -f junk ] if double brackets is giving the yuck.
In practice, the only noticeable difference I have witnessed is
I can write the whole thing in a single line (which is essential in GUI and interactive contexts) and it reads well.I have never seen the second version. Apparently it's there since bash 3.00 (2004). Maybe took inspiration from zsh who also has (or a common ancestor ?)
The former is easier to remember. You can't forget the semicolon if there isn't a semicolon to forget.
It depends on where you're coming from.
To myself, I agree, but to a Windows native power user, the latter looks confusing.
Source: Windows native colleagues.
Imagine though, if we shell-heads came over to Windows and started writing an entirely new shell to replace Powershell because we didn't want to learn Powershell. It's just so utterly bizarre to me. I guess people like what they like, and that's cool, but wanting to rip out a 40+ year old scripting environment and command line shell because it doesn't look like goddamn Ruby or Clojure or Rust or whatever is just intolerable.
I have always struggled a bit with shell replacements. I use zsh but only because of oh-my-zsh. Apart from that I always thought of shell scripts as a necessary evil for interoperability. Today you can usually expect a linux system to have bash or at least sh. That is why I do shell scripting. Nushell is usally not preinstalled on a system and so I cannot expect it.
If I want to do real scripting/programming I use python or another dedicated programming language. I don't really know what the value of Nushell is for me. Maybe the plugin system is amazing but at the moment I miss nothing in my zsh.
I really would like a new shell that wasn't based on a poorly designed programming language from the 1960s[1][2]
However, I need to know sh/bash well because they're the tools installed by default; in any "well-established" organization, getting approval to install a new shell will range from "12 to 24 months" to "impossible". And without that, I'm not going to put in the effort to learn a new tool that is only useful some of the time and requires massive context switching.
[1] https://en.wikipedia.org/wiki/ALGOL_68 [2] https://en.wikipedia.org/wiki/Bourne_shell#:~:text=Stephen%2...
That's what I mean. A new shell would need to blow me away with some amazing must have interactive feature. The scripting part is, at least for me, not really relevant. If I can install software on the target I will install a proper language and if not then it will be bash or sh anyways, even though they properly suck.
The "killer app" is that it's easy to string together multiple commands and have them work more reliably than shells that rely on plaintext. In other words, it's something in-between running individual commands and writing full scripts. I've not used Nushell before, but I'm very familiar with PowerShell which is similar, and it's ridiculously easy to manipulate and explore your file system with confidence that you don't have to rely on hacky and hard to read regex and similar suboptimal solutions.
Python is good for general-purpose scripting, which does cover most of the tasks, but it’s still too bureaucratic when it comes to OS primitives. And when a small script at hand is tightly related to some OS thing anyway, it’s not a disservice to write it in shell.
Python's main distinction from a shell scripting language is that external program invocations are not first-class citizen. Also no easy ways to feed/read the subprocess's std io.
Coming from the shell, one of the most annoying things about Python is working with files. In the shell I can read and write to files on the filesystem with basically no friction and no extra infrastructure. Just a "cat" command or a <, >, or >>. The ease at which input and output can just get tossed around in the shell is the biggest thing I end up missing when I graduate up to any "real" language.
I remember when I first learned how to work with files in Python and thought "Damn, y'all live like this?"
It is not just about scripting but the structure of input and output. Also no need to give up (z)sh switching shells is eazy.
Maybe I need to get into nushell more but my feeling is that if it's a simple problem it the benefit will be negligible and if it is too complicated for that I will probably write a python script.
That was my feeling as well. Why learn some not-used-anywhere-else scripting language when we have bash/zsh with battle tested scripts and snippets? Also, nushell will probably break everything that expects a normal bash/zsh/fish.
I’d probably rather use xonsh as I do more complex scripts in Python anyways.
That is how I felt with Zsh, even though Zsh scripting is a step up from Bash. But with Nushell there is a huge space of scripts I now prefer to write in it.
I use zsh because of oh-my-zsh. I don't any of the scripting features.
We all know the dueling aphorisms of "if it ain't broke, don't fix it" versus "no risk, no reward", so I'll just say this: there is a middle way. I keep a whole lotta Zsh and Bash scripts. But for work on systems I control, Nushell is a boon. I use it for interactive work and add scripts when I see a need.
Nushell commands are really great, so great that they are even better than the standard library of some languages. However, the language itself isn't very intuitive to learn.
I wish Nushell and Python/TypeScript have a baby one day.
> I wish Nushell and Python/TypeScript have a baby one day.
That would be nice. Or a TypeScript transpiler to rust ;)
well if you want a python/shell hybrid there's always xonsh (https://xon.sh/). Really great in particular for people like me who are bash-challenged. I do like Nushell too but I also always had problems remembering the actual language.
I actually meant something like that with Nushell commands. They output structured data that Python and JavaScript can easily leverage in theory.
I really wanted to get into nushell but i found reedline to be very limiting in a few specific ways esp around keybindings that blocked me from moving to it
Anyone knows how good is the vi mode ?
My pet peeve with nushell: broken tables
https://github.com/nushell/nushell/issues/13601
https://github.com/nushell/nushell/issues/16379
This is the second time I’m hearing of Nushell.
I wanted to try it the first time I heard about it but completely slipped my mind so this is a good reminder.
I’ve created a small utility script at work that automates some routine tasks and nicely formats the collected data in a table, and I can say that Nushell is an amazing tool.
this is very weird timing, I literally just installed nushell this morning lol. I like it so far but that may just be the novelty effect. I gotta find a syntax file for vim, tho, because moving over my bash aliases and trying to visually parse the config file after 10 lines or so is making me go cross-eyed.
caveat up front: I see that the point here is to talk about a nice, good thing for people to use that is useful, and I don't think that's a bad thing. I am also always looking for ways to upgrade, and I also agree that in a modern context with modern knowledge, we can do better.
However, regarding the posix skepticism - I think OP has missed (or just not mentioned) the actual thing that keeps bash/zsh from being unseated.
Industrial standards are a good thing just because they’re standards. They’re right that a redesign would be superior in terms of raw design, but this is only useful if it’s adopted widely enough so that you don’t have to context switch between two fundamental systems. I spin up a new VM somewhere and it's going to have bash. I use a tool and I expect it to follow a particular convention - having to figure out which I'm reaching for adds an amount of friction that would make most work untenable.
I like zsh but I also want something better. Type safety and robust completions would make me very happy, but if we're going to make the switch we have to do it as an industry - with a set of agreed upon interfaces and standards that are carefully thought out and built on consensus. I don't know if that's possible given the massive complexity of the state of affairs but that's what it would take.
A nice coincidence to read this; I was just telling some friends the following (lightly edited):
Nushell is amazing and a total pleasure to use. I cannot yet discern any limit to how much thought has been put into it.
I’m stunned in a good way. I’m writing shell scripts without any pain — actually I much prefer them to Python! With the language-server integration – I use Zed, but I'm sure they exist in VS Code and others too – I can see errors in scripts as I write them! (Including typos in pathnames! Amazing.)
I have to admit Nushell didn’t become my daily driver right away; it took a few years for me to switch fully. I don't know exactly why, but it probably had to do with its lack of POSIX compatibility. I now see this as a necessary break for Nushell to pursue its vision.
About expectations: some people will be delighted immediately and get hooked, but not all. We're all busy and adopting a new tool can feel like a leap of faith. For me, it has been worth it. Nushell has felt like planting a garden that gives back way more than you put into it.
I wrote up a quick gist [1] that shows how nice the experience is to write a new command (i.e. function) in Nushell.
[1]: "Building Argsort with Nushell" https://news.ycombinator.com/item?id=46528644
If you haven't tried PowerShell I strongly recommend you do. It is really well designed and the way objects are piped between commands is brilliant and very powerful. Combined with property filters you can do SQL like queries. The ConvertTo-JSON lets you export the output of any command to JSON which is amazingly useful. As an example you can dump the entire Active Directory (Assuming you have permissions) by
Get-ADObject -Filter * -Properties * | ConvertTo-JSON > ADObjects.json
And you have access to ALL of the .NET library.
Until you have to quote a string that has ampersands in it :)
You mean like this...
' "Here is an ampersand... &" '
To clarify, in PowerShell there is a difference between text between single quotes (e.g. '$test') and double quotes (e.g. "$test"). Single quote strings are literal strings, so whatever text is contained within them is reproduced as written. Double quote strings are expandable strings, which means that certain text inside the string is evaluated before it is returned. If you have double quotes in a literal string, you'll see double quotes within that string, and the same should be true for ampersands.
I started using nushell around April 2024. While it is much better than other shell languages, the lack of proper types is painful.
Shell languages make sense if you believe in the Unix philosophy. For me, the problem with the Unix philosophy is the endless serialization and deserialization as well as lack of proper error handling. So nushell for me is a good answer to an ill-posed question.
The approach I have been taking is a single binary with a billion subcommands and aliasing these. I currently have two of these in Rust, one in Swift. I tried going all Rust but integrating with certain aspects of macOS is just so much simpler in Swift.
Like the recent push to make CLI development suck less (e.g. argument parsing used to be painful but is solved now) has made developing CLI tools a lot less painful.
serialization/deserialization will always be needed unless you got all your programs working with the same ABI. it's just that in nushell's case you aren't serialize to human readable text.
endless serialization and deserialization is what makes me hate Bash and love PowerShell which solves this issue by piping full objects between commands and the ConvertTo-JSON command.
i've never used nushell, but i've always felt that people have been sleeping on PowerShell.
yes, it was _originally_ only for Windows, but PowerShell 6+ uses .NET Core, which is OS independent. this means that a few helper functions like GeneratePassword[0] are gone, but it's _mostly_ at parity with .NET.
the Verb-Noun structure can be confusing at first, but once you know the approved verbs[1], you can usually guess your way through command discovery, which is not something i can say for most POSIX tools (useradd and adduser do different things!!)
it's also object oriented by design, with default aliases like ?[2] and %[3], querying structured data is a breeze.
- want to check a CSV? Import-CSV[4].
- want to call a REST/SOAP endpoint? Invoke-RestMethod[5] has you covered.
- DNS queries? Resolve-DnsName[6]
as it's built on top of .NET, you get the whole CLR[7] at your fingertips! you can make a TCP client[8] in PowerShell, or even just write C# directly in your terminal[9] and execute it the same way.
such a flexible and useful language, even if it is a little slow and owned by micro$oft. but it _is_ open source[10]!
---
[0]: https://learn.microsoft.com/dotnet/api/system.web.security.m...
[1]: https://learn.microsoft.com/powershell/scripting/developer/c...
[2]: https://learn.microsoft.com/powershell/module/microsoft.powe...
[3]: https://learn.microsoft.com/powershell/module/microsoft.powe...
[4]: https://learn.microsoft.com/powershell/module/microsoft.powe...
[5]: https://learn.microsoft.com/powershell/module/microsoft.powe...
[6]: https://learn.microsoft.com/powershell/module/dnsclient/reso...
[7]: https://learn.microsoft.com/dotnet/standard/clr
[8]: https://learn.microsoft.com/dotnet/api/system.net.sockets.tc...
[9]: https://devblogs.microsoft.com/scripting/weekend-scripter-ru...
[10]: https://github.com/PowerShell/PowerShell
As a prior contributor to PowerShell, I think part of this obscurity reason is how they neglected their community. This was evident in their merged PR history only containing commits from Microsoft developers.
I use nushell now, and its community is fantastic. It may face breaking changes every so often, but it has a much faster execution speed and more features if you're not tied into the .NET ecosystem.
Powershell is pretty great, though I am constantly bit by issues with filenames having [ or ] in them and end up having to pass -LiteralPath to everything, which is frustrating and a constant source of bugs in any other scripts that do not do that.
> The truth is, in 2023 if someone asked us to design a system, we wouldn't design POSIX.
You can design anything you want (see GTK for an example of moving target). But if you want anyone to use it, better stick to standards.
Nushell is a fantastic project.
Something I came to appreciate is that the 50MB binary is really battery included. You will be able to deal with JSON, XML, SQLite DBs, HTTP requests and more. I personally do not need anything else.
Now, no matter how much you get excited about it, do not write too much production code with it as it still change and break often between releases.
Do not let the "shell" in the name fool you. Nu is a full on programming language. I've spent more time with it than pretty much any other lang and if I have to describe it in one sentence, I'd say: It's the most beautiful combination of the ease of Python, strictness and ergonomics of Rust and of course shell capabilities of Bash.
It's really its own kind of thing. It's definitely not just another shell.
I've written very impressive and very complex software in nu. I fully expect it to take off very fast as it nears a stable v1.0. I can't imagine going back to anything else.
The example FOR loop in BASH is missing a trick to make it easier to read:
(Though I prefer using printf than echo as it's more capable and POSIX compliant)I write far too much stuff in BASH, but for me it's just not worth moving to using a different shell due to its ubiquity. There's also the question of "will this still run easily in 20 years". Of course, BASH is a nightmare for bugs and foot-guns unless you make a point of defensive coding (e.g. surround variables with double-quotes and using Shellcheck to point out common errors).
By the way, the article goes on to mention the large number of options to "ls". Don't try to parse the output of "ls" in scripts as there's better ways to do things: https://mywiki.wooledge.org/ParsingLs
From an end-user point of view, there are some weirdnesses in Nushell, but they are rare in my experience. Here is one that gotcha'ed me:
The above does not return the sum (1 + 2 + 3 = 6). Why? Because `sum` is a *nix utility for returning the checksum. The way to do it in Nushell is: More info at [1]. Technically, this isn't Nushell's fault; it is just delegating to an external command.* Still, I found it confusing at first.* Maybe it is time to rename `sum` to `checksum`!
[1]: https://github.com/nushell/nushell/discussions/17239