Live data from Hacker News

Nushell and Uutils

nushell.sh

11–20 of 20 posts

Re: Nushell and Uutils

#11
post #8
post #5

Earlier quoted context omitted.

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).

Re: Nushell and Uutils

#12
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.

Re: Nushell and Uutils

#13
post #8

Earlier quoted context omitted.

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.

Re: Nushell and Uutils

#14
post #12

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…

[deleted]

Re: Nushell and Uutils

#15
post #12

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…

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.

Re: Nushell and Uutils

#16
post #15
post #12

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…

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.

Re: Nushell and Uutils

#17
post #2

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.

> 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.

Re: Nushell and Uutils

#18

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.

Re: Nushell and Uutils

#20
post #2

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.

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.
Post reply on HN