- 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.)
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 love Powershell and I wish MSFT would put a concerted effort into optimizing its performance.
I've never experienced startup times anything close to a minute. Is your computer very old?
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.
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.
for i in 1..10 {
print $i
}really all that more readable than
for i in {1..10}; do
print $i
doneLike, am I taking crazy pills? They're basically exactly the same!
for i in `seq 10`
do
print $i
done
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]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
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.
for (f in *.c) if (test -f $f) cc $f
I can write the whole thing in a single line (which is essential in GUI and interactive contexts) and it reads well.To myself, I agree, but to a Windows native power user, the latter looks confusing.
Source: Windows native colleagues.
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.
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?"
I’d probably rather use xonsh as I do more complex scripts in Python anyways.
I wish Nushell and Python/TypeScript have a baby one day.
That would be nice. Or a TypeScript transpiler to rust ;)
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 │
╰────┴────────────────────────┴─────────┴─────────┴──────────────╯I wanted to try it the first time I heard about it but completely slipped my mind so this is a good reminder.