Nushell and Uutils(nushell.sh)
nushell.sh
Nushell and Uutils
https://www.nushell.sh/blog/2023-09-05-why-uu.html
19 comments
In a way, this is cool. But I am also confused. Why does a shell include commands? Is this the beginning of a new type of distribution? A new type of GNU perhaps? Probably not. But I am not completely following what this provides that the two projects independently would not.
I presume the reason they do it is that the premise of Nushell is that it uses pipes of structured output instead of simple text streams. That means that they need all the tools to output datas in that form. They could include wrappers for all OS provided binaries and handle the conversion in those wrappers, but that makes you incredibly fragile to minor output or flags changes, and in many cases those wrappers would end up being more complex than the complex than the commands themselves.
Current shells include [lots of builtins](https://www.unix.com/man-page/freebsd/1/builtin/), I don't think including a `cp` or `mv` that fits a shell with a different style is that different
Good point. I wonder if there was some criteria that determined if a utility were to be a command or a builtin, originally. I thought a shell first and foremost was about working with processes, and a little less about working with files. But both are obviously needed, one way or another, so will be interesting to see what becomes of this.
Based on list seems builtin functionality is what is used to work with processes (nohup, kill, etc), environment (where, which, etc), and for shell as programming language ([, while, etc).
Yes. As an example, the source builtin would not be possible to implement as a command as a child process can't change its parent's environment. So those types of concerns play in I think.
One benefit is portability. Writing a script utilizing those commands won't depend on those tools being available, only the shell. Another potential one is performance. In the specific case of nushell which is object-based it may also needed for piping object-data.
It's actually something that bothers me about nushell. The assumption seems to be that you have to parse the output of external commands. I think that ideally there should be some metadata that an executable could have to indicate that it can output structured data and nushell could pick it up without the user having to explicitly parse it. That way you could write commands that work on other shells but work better on shells that understand structured data.
> Why does a shell include commands?
I'd like to think in part for us poor souls who must work on a Windows machine but are used to working in a Linux shell.
I'd like to think in part for us poor souls who must work on a Windows machine but are used to working in a Linux shell.
I suppose this particular shell includes a ton of functions/commands already.
Interestingly the only other shell that has such more complex functionality integrated is pwsh that nushell is inspired from.
Sort of. In pwsh on Linux, ls and cp are the same binaries you'd call from bash. The Powershell equivalents, aliased to gci and copy, are implemented in Powershell, but not part of the shell, they are modules. Some core modules ship with the shell, everything else comes from the package manager (Install-Module). There is a very small set of commands implemented directly in the shell - Import-Module, e.g.
Every command is implemented in a module, it's just that pwsh ships with several core modules.
Every command is implemented in a module, it's just that pwsh ships with several core modules.
I am looking forward to NuShell 1.0.0, where they finally add email support:
https://wikipedia.org/wiki/Jamie_Zawinski#Zawinski's_Law
https://wikipedia.org/wiki/Jamie_Zawinski#Zawinski's_Law
[deleted]
Congrats to the nutshell team!
I'm a seeming nobody (hurrah new HN accounts) but I cannot express how much excitement I have for nushell, and this only intensifies it. Practical, and progresses towards resolving one of my only complaints with nushell currently. Don't sleep on nushell. I've never regretted reaching for it. You think jq is 'good', but only because you haven't nushell. Maybe it's the (insert tool that gives me my exact dev env on any Linux-y machine I can walk up to) but nushell is invaluable to me. I was shocked the other day when tired-me wrote a shell script and started employing my usual bash-isms before changing the shebang to nushell and embracing serenity. Mad respect for JT and the folks that JT has attracted.
I am also excited, but I think I am too old to jump in on a new way of shell workings. My fingers are too used to type bash and coreutils switches.
Right, but I think that's the point. If nushell adopts uutils, I don't have to remember that nushell's mkdir already implies `mkdir -p` and breaks if I specify it.
Instead, I get to use familiar coreutils primitives, while also benefit from the insane power of sane string handling, string interpolation, native JSON handling, records, scoping, etc. And forgetting so much bashisms that I groan when I pop a nix shell and end up in bash/zsh.
Honestly, nushell takes so little time to adopt and has so many tag-along benefits. The biggest friction has been around quirks of `mkdir`, `mv`, `cp`. Someone... I know... recently filed a bug on their `mv` not working right, so I am very happy to see this.
Instead, I get to use familiar coreutils primitives, while also benefit from the insane power of sane string handling, string interpolation, native JSON handling, records, scoping, etc. And forgetting so much bashisms that I groan when I pop a nix shell and end up in bash/zsh.
Honestly, nushell takes so little time to adopt and has so many tag-along benefits. The biggest friction has been around quirks of `mkdir`, `mv`, `cp`. Someone... I know... recently filed a bug on their `mv` not working right, so I am very happy to see this.
[deleted]