[1 2 3] | sum
[1 2 3] | math sum
* Maybe it is time to rename `sum` to `checksum`!
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...
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.
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.
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’d probably rather use xonsh as I do more complex scripts in Python anyways.
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...
I remember when I first learned how to work with files in Python and thought "Damn, y'all live like this?"
for i in {1..10}; do
echo $i
done
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
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.
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.
I've never experienced startup times anything close to a minute. Is your computer very old?
I love Powershell and I wish MSFT would put a concerted effort into optimizing its performance.
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.
May you enjoy the trip, my friend. You deserve it.
Get-ADObject -Filter * -Properties * | ConvertTo-JSON > ADObjects.json
And you have access to ALL of the .NET library.
' "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.
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.
I wish Nushell and Python/TypeScript have a baby one day.
C: > ls
╭────┬────────────────────────┬─────────┬─────────┬──────────────╮
│ # │ name │ type │ size │ modified │
├────┼────────────────────────┼─────────┼─────────┼──────────────┤
│ 0 │ Program Files │ dir │ 8.1 kB │ 2 hours ago │
│ 1 │ Program Files (x86) │ dir │ 8.1 kB │ 2 months ago │
│ 2 │ Users │ dir │ 4.0 kB │ 4 months ago │
│ 3 │ Windows │ dir │ 16.3 kB │ 4 days ago │
╰────┴────────────────────────┴─────────┴─────────┴──────────────╯That would be nice. Or a TypeScript transpiler to rust ;)
for i in 1..10 {
print $i
really all that more readable than
for i in {1..10}; do
print $i
Like, am I taking crazy pills? They're basically exactly the same!
for i in `seq 10`
do
print $i
done
if (test -f junk) rm junk
if test -f junk; then rm junk; fi
1: Rc—The Plan 9 Shell https://9p.io/sys/doc/rc.html
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
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.
for (f in *.c) if (test -f $f) cc $f
To myself, I agree, but to a Windows native power user, the latter looks confusing.
Source: Windows native colleagues.
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.
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.
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.
- 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.)
I wanted to try it the first time I heard about it but completely slipped my mind so this is a good reminder.
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.
xpe•1d ago
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