“Ask and ye shell receive”: I swear I was just complaining about bash, zsh and the lot the other day saying that we needed a modern alternative shell without ridiculous names and design choices. Installing this tonight! So excited!
Nushell: Introduction to a new kind of shell
151–160 of 252 posts
Re: Nushell: Introduction to a new kind of shell
#152Having written a lot of shell scripts, the single greatest thing I've ever experienced is shell-friendly outputs. For example, consider if ls had a "--shell" option that output each entry as a single line of shell-quoted variables safe for eval: # cd /usr/share/dict # ls --shell words path="/usr/share/dict" file="words" user="root" group="root" size=985084 ... Then all sorts of things become easy. # eval $(ls --shell…
jc [0] is dedicated to providing this externally for common commands, but I agree that it would be better if command authors built it in as an option. It would make shell scripts shorter, more readable, and less buggy.
Re: Nushell: Introduction to a new kind of shell
#153Having written a lot of shell scripts, the single greatest thing I've ever experienced is shell-friendly outputs. For example, consider if ls had a "--shell" option that output each entry as a single line of shell-quoted variables safe for eval: # cd /usr/share/dict # ls --shell words path="/usr/share/dict" file="words" user="root" group="root" size=985084 ... Then all sorts of things become easy. # eval $(ls --shell…
I like the idea, but if it was interpreted directly, that would be a security nightmare unless we also had something like Python's ast.literal_eval(). Which makes us come back to JSON-like outputs because we need some form of serialization anyway, I guess.
Of course there could be some tweaks like a scoped eval to prevent stomping on the script's variables, but it's really not very hard for a C program to escape shell variables correctly and safely.
You could have an eval that only read variables, but trusting a program to only return variables is a really low bar; it's very hard to mess that up.
Re: Nushell: Introduction to a new kind of shell
#154Earlier quoted context omitted.
Why use this over PowerShell for example?
It's dumb but I personally can't get over Camel-Kebab-Case commands. I hate typing Caps, and hyphens.
PowerShell is case-insensitive, you don't need to type caps for variable/function references if you don't want to. You'll still have hyphens, but in an interactive shell (as opposed to a script) there are many aliases you could use that avoid hyphens (or you can make your own).
https://learn.microsoft.com/en-us/powershell/module/microsof...
Re: Nushell: Introduction to a new kind of shell
#155Having written a lot of shell scripts, the single greatest thing I've ever experienced is shell-friendly outputs. For example, consider if ls had a "--shell" option that output each entry as a single line of shell-quoted variables safe for eval: # cd /usr/share/dict # ls --shell words path="/usr/share/dict" file="words" user="root" group="root" size=985084 ... Then all sorts of things become easy. # eval $(ls --shell…
> Having written a lot of shell scripts, the single greatest thing I've ever experienced is shell-friendly outputs.
This is basically the idea of PowerShell. Output is well formatted data that can be passed around and manipulated in a regular manner. No slicing on columns or anything like that.
PowerShell has other issues (many of which are documented in these very comments!) but shell friendly output is one of its central ideas.
Re: Nushell: Introduction to a new kind of shell
#156Having written a lot of shell scripts, the single greatest thing I've ever experienced is shell-friendly outputs. For example, consider if ls had a "--shell" option that output each entry as a single line of shell-quoted variables safe for eval: # cd /usr/share/dict # ls --shell words path="/usr/share/dict" file="words" user="root" group="root" size=985084 ... Then all sorts of things become easy. # eval $(ls --shell…
Well in nushell you wouldn't be using the coreutils commands, you'd be using the nushell builtin replacements. Those builtins return structured data.
Now for the 1000 other non-coreutils commands on your system, that's not very helpful. --shell is a good idea, though it seems like JSON is becoming the most common alternative structured output implemented by commands. Nushell and PowerShell can turn JSON into a structured variable easily, though using jq in shell is alright most of the time.
Re: Nushell: Introduction to a new kind of shell
#157Earlier quoted context omitted.
Do you use pwsh as your daily driver? I find that its commands are as easily memorable as any other shell. That being said You should enable these: Set-PSReadLineKeyHandler -Key Tab -Function MenuComplete Set-PSReadLineOption -PredictionSource History MenuComplete will give you a menu of arguments that each command takes so you can easily see them when pressing tab for completions and prediction source will try to pr…
Also make sure you're on latest version of PSReadLine (I had some problems with it not updating properly and had to do a manual `Install-Module PSReadLine -Force`) and try Set-PSReadLineOption -PredictionSource HistoryAndPlugin -PredictionViewStyle ListView You can also toggle between the default inline and listview with F2. Also if you install Install-Module CompletionPredictor and add this to your profile: Import-M…
Thanks! I haven't seen CompletionPredictor before. I'll give it a shot.
Re: Nushell: Introduction to a new kind of shell
#158I use it as my primary driver, for the sole reason is that it's the only cross-platform shell that properly supports Windows (without resorting to Cygwin/MSYS, which has performance issues and many pain points). I'm still getting used to the syntax though... (Edit: forgot to mention Powershell, since nowadays it also works on Macs and Linux)
Why use this over PowerShell for example?
Some reasons I prefer Nushell over PowerShell:
- less verbose syntax
- better cross-platform support (PowerShell is technically cross-platform, but it has some baggage from its Windows-first history)
- way faster to start up
I'm a little biased (I'm a member of the Nushell core team), but those are all things that drew me to start contributing to Nushell.
On the other hand, Nushell is certainly less mature+stable than PowerShell.
Re: Nushell: Introduction to a new kind of shell
#159Earlier quoted context omitted.
Just get the 7th path from `Get-Location` and `Set-Location` there, e.g. function Set-StackLocation ($Position) { (gl -Stack).Path | select -Index $Position | cd }
Seems like a lot of work for something that's just built into bash and is extremely useful.
Like all shells, PowerShell is split between being a scripting language and an interactive shell.
PowerShell leans a bit more towards being a scripting language than an interactive shell, so things are more verbose, as befits a shell script that needs to be read and updated later by a different programmer.
But yeah, lots of little trade offs like that permeate the language.
Re: Nushell: Introduction to a new kind of shell
#160Earlier quoted context omitted.
Honestly I’ve enjoyed working with PowerShell for scripts to work for all developers on my team regardless of what OS they are using.
I wanted to like Powershell, but it is missing some features that I think are essential. For example, apparently checking the return status of an arbitrary command is not trivial, and there's no equivalent of `-eu -o pipefail`. Yes, I know `-eu -o pipefail` is imperfect too, but it covers most common cases. I also struggled badly to stop it from mangling the output encoding of my applications (no, I don't want a godd…
> For example, apparently checking the return status of an arbitrary command is not trivial
You mean the fact that it gets put into the $LASTEXITCODE variable instead of putting the command directly into the conditional?