Nushell – A New Type of Shell(nushell.sh)
nushell.sh
Nushell – A New Type of Shell
https://www.nushell.sh/
37 comments
doubly so because it's not really a "book" it's just a ...booklet? guide? with 13 pages (one of which is installation) and none of them are particularly long.
Just curious why you think so. Bash manuals tend to be pretty long and it seems they also provide a quick reference for commands right in the same docs page. Is it the "book" aspect of it?
Because a book is a big upfront cognitive investment - and if it's written well, it will begin with the assumption that you already want to use Nushell, because why else would you have the book?
If you want to entice users, they need to see something immediately valuable, and it needs to come with essentially no investment on their part.
If you want to entice users, they need to see something immediately valuable, and it needs to come with essentially no investment on their part.
We've seen earlier posts of this. It's a shell that works on the premise that data is tabular. It's pretty neat. I'm not sure I can ever leave the traditional Unix shells behind though. I'm much more interested in a shell integrated with jq or something like that, but the reality is that Unix commands' input and output data types are not very well described or strongly typed, and that makes anything much better than the shell's we've got difficult to deal with.
I wonder if we could have a standard by which a command could indicate what input and output data types it consumes/produces for a given command-line, as well as what sorts of side-effects a command-line might have... Then we could have shells implement some type system. Where you expect XML you can use XPath, where you expect JSON you can use jq, and so on, and the shell could display tabulated output where possible, and not where not.
I wonder if we could have a standard by which a command could indicate what input and output data types it consumes/produces for a given command-line, as well as what sorts of side-effects a command-line might have... Then we could have shells implement some type system. Where you expect XML you can use XPath, where you expect JSON you can use jq, and so on, and the shell could display tabulated output where possible, and not where not.
> I wonder if we could have a standard by which a command could indicate what input and output data types it consumes/produces for a given command-line
I have suggested something very similar in the past, see my below comments:
https://news.ycombinator.com/item?id=14675847
https://news.ycombinator.com/item?id=17882025
https://news.ycombinator.com/item?id=17880897
I have suggested something very similar in the past, see my below comments:
https://news.ycombinator.com/item?id=14675847
https://news.ycombinator.com/item?id=17882025
https://news.ycombinator.com/item?id=17880897
I was thinking of something more static than dynamic. In any case, I suspect neither is workable.
A friend of mine worked on a shell based on jq a few years ago: https://github.com/jq-shell/jqsh
That's really interesting, thanks for sharing.
Have piped process communicate with HTTP and use content negotiation headers?
I've been using nu as my main shell for... a month now? Happy to answer any questions.
I am not a heavy shell user, (I do almost everything in a terminal or a web browser, I just don't use shell-specific features a ton) and there's been some adjustment, but I like it!
I am not a heavy shell user, (I do almost everything in a terminal or a web browser, I just don't use shell-specific features a ton) and there's been some adjustment, but I like it!
One thing I'm wondering: I know that you have to do some "massaging" of programs' output, to get it into nushell's named-columns model. For example, the "Parse formatted commit messages" in the cookbook: https://www.nushell.sh/cookbook/en/git.html. You specify a custom format string, then split it, and name the columns.
Did you have to spend a lot of time doing that kind of massaging?
Did you have to spend a lot of time doing that kind of massaging?
I have mostly used this stuff with built in commands and so haven’t had to do a ton of massaging.
I'm curious if you've ever played with powershell or jq/jc/jsonifying *sh and how this compares?
I had a period when I was mainly on windows where I quite enjoyed powershell and now that I'm back on linux I moved to trying jq/jc. Nushell seems pretty interesting.
I had a period when I was mainly on windows where I quite enjoyed powershell and now that I'm back on linux I moved to trying jq/jc. Nushell seems pretty interesting.
I used Powershell for the past few years. There’s a lot more stuff out there for PS, which is both good and bad.
This place is as good a place for this link as any: https://tkatchev.bitbucket.io/tab/
Enjoy. :)
P.S., Not spam, I'm the author.
Enjoy. :)
P.S., Not spam, I'm the author.
One thing I think the nushell guys should include in their "about" page is an answer to the question, "how is this different from PowerShell?"
The analogy to PowerShell is unavoidable -- they even make it themselves in the docs. I'm totally willing to believe there are important differences, but I wish they'd highlight them straight off the bat.
The analogy to PowerShell is unavoidable -- they even make it themselves in the docs. I'm totally willing to believe there are important differences, but I wish they'd highlight them straight off the bat.
I love the concept of this. Something like this for JSON would be great. Kind of sick of `jq`.
Have you seen jc[0]? Now for the json bash interface the only thing that's missing a nicer json renderer (perhaps table format) to have a similar feature parity to Nushell.
[0]: https://github.com/kellyjonbrazil/jc
[0]: https://github.com/kellyjonbrazil/jc
I'm not sure if this fits your use case, but I also created jtbl to print the json output (say from jc) as a table in the terminal.
https://github.com/kellyjonbrazil/jtbl
https://github.com/kellyjonbrazil/jtbl
Interesting project, it'll definitely be something I consider! I've been hacking together things with gron[0] and coreutils when I do want tabular data. jello looks pretty interesting too, but I'm not sure if I agree with python syntax.
[0]: https://github.com/tomnomnom/gron
[0]: https://github.com/tomnomnom/gron
Yep, I get it with the python syntax. It's not for everyone but the goal is to democratize the JSON processing for the masses that know python where more complex jq queries can be daunting. Jello also supports gron-like output with the -s option.
It looks like this is trying to do what powershell does pretty well. Pushing tabular data through pipes and filtering on columns and rows and such. It helps that all the commands in powershell outputs tabular data. Has anyone tried using powershell on linux?
I used powershell a bit when I was mainly using Windows and tried it briefly when moving back to Linux. The biggest issue is when you're stepping outside of powershell commands which return nice objects and run linux scripts or executables. Eventually I took the path of least resistance and just switched to bash with jq/jc to fulfill my structured needs, but I'm sure someone could create a jc for gnu/etc to powershell.
I've used it on Linux. It works well. There are some issues with cmdlets and sudo, and when using regular gnu tooling as it's not within the pipeline, but overall the experience was positive.
This looks good in theory, but in practice many of its examples are cheating: `ps`, `ls`, etc. are something like shell builtins, so your memorized `ps` arguments won't work with this, for example.
Isn't it enough to just provide a formatter for use with existing shells?
This seems like something that could be useful for data scientists.
Compare to Powershell, which also works with structured objects.
I’ve been thinking about what I’d want in a new shell for a little while. Suffice it to say: not this.
This decides that the problem is mostly the unix commands not working together the way the author would like but I’m already pretty happy with the way unix commands work, I know how to use awk and I have a bunch of tools for different kinds of structured data.
So instead I will go off topic and describe the new shell that I would actually like to see:
A shell is (at least as far as I’m concerned) a program for running other programs, and connecting them together. I would not constrain myself to running inside a fixed grid character terminal if I could help it.
The thing I would focus on is interactivity and modifiability of commands. Most of my time at a command line is doing one of two things:
1. Typing simple commands to e.g. start systems or query their state or otherwise poke them. Here command has a more traditional meaning than “invocation of a program which may do arbitrary things”.
2. Piecing together pipelines to extract some data and do things with it (first I write a command to get some data and probably pipe it into less, then I try writing a bit of sed on the end and piping that into less, then some awk, and so on until I have the pipeline I want)
For 1, I would want things to mostly work like bash.
For 2, I would want something more. Instead of using regular pipes, add an intermediate program (or use the shell). At first it can just hold onto the input as well as sending it to the output. That would make it easy to inspect what is going into a pipe. I guess it may eventually want to stop building memory usage so maybe it could have a large ring buffer instead. I would also like to be able to get some pv like behaviour to see progress. This could also be switched into something with lower overhead. I think it would all be reasonably cheap with splice, tee, and vmsplice (I’m not interested in support for non Linux platforms).
I’d want the ability to e.g. write my command with a trailing pipe, see some output, and then interactively add more stages to the pipeline
Ideally, I’d like an interactive awk-like tool where I can see the effect of my partly-written command as I write it.
I’d want ssh to be treated in a first-class reasonably transparent way where I don’t need to think about complicated quoting rules. But maybe somehow efficiently trying to avoid too much bandwidth or remote computation.
I think I would want it to mostly run inside emacs but able to spawn a fast terminal emulator automatically as necessary for large files or long lines (you may be surprised to know that a shell in emacs tends to give you much lower typing latency than typical terminal emulators because Mac’s handles its own rendering and line editing whereas a terminal emulator must send the key to bash through a pty which then sends back some terminal control codes which must be interpreted before the display may be rendered.
This decides that the problem is mostly the unix commands not working together the way the author would like but I’m already pretty happy with the way unix commands work, I know how to use awk and I have a bunch of tools for different kinds of structured data.
So instead I will go off topic and describe the new shell that I would actually like to see:
A shell is (at least as far as I’m concerned) a program for running other programs, and connecting them together. I would not constrain myself to running inside a fixed grid character terminal if I could help it.
The thing I would focus on is interactivity and modifiability of commands. Most of my time at a command line is doing one of two things:
1. Typing simple commands to e.g. start systems or query their state or otherwise poke them. Here command has a more traditional meaning than “invocation of a program which may do arbitrary things”.
2. Piecing together pipelines to extract some data and do things with it (first I write a command to get some data and probably pipe it into less, then I try writing a bit of sed on the end and piping that into less, then some awk, and so on until I have the pipeline I want)
For 1, I would want things to mostly work like bash.
For 2, I would want something more. Instead of using regular pipes, add an intermediate program (or use the shell). At first it can just hold onto the input as well as sending it to the output. That would make it easy to inspect what is going into a pipe. I guess it may eventually want to stop building memory usage so maybe it could have a large ring buffer instead. I would also like to be able to get some pv like behaviour to see progress. This could also be switched into something with lower overhead. I think it would all be reasonably cheap with splice, tee, and vmsplice (I’m not interested in support for non Linux platforms).
I’d want the ability to e.g. write my command with a trailing pipe, see some output, and then interactively add more stages to the pipeline
Ideally, I’d like an interactive awk-like tool where I can see the effect of my partly-written command as I write it.
I’d want ssh to be treated in a first-class reasonably transparent way where I don’t need to think about complicated quoting rules. But maybe somehow efficiently trying to avoid too much bandwidth or remote computation.
I think I would want it to mostly run inside emacs but able to spawn a fast terminal emulator automatically as necessary for large files or long lines (you may be surprised to know that a shell in emacs tends to give you much lower typing latency than typical terminal emulators because Mac’s handles its own rendering and line editing whereas a terminal emulator must send the key to bash through a pty which then sends back some terminal control codes which must be interpreted before the display may be rendered.
... the Wolfram Shell?
That... is not a good way to entice me to try something.