Live data from Hacker News

Nushell: Introduction to a new kind of shell

dataswamp.org

201–210 of 252 posts

Re: Nushell: Introduction to a new kind of shell

#201
post #163

Earlier quoted context omitted.

Seems like a lot of work for something that's just built into bash and is extremely useful.

Less work than trying to add named stacks to bash. If it's so central to your workflow that you're willing to put up with the rest of bash just for it, adding a couple lines to your profile can't be that big of a deal.

Well, it's the first time I saw the magic incantation listed above so I may give it another try know.

Re: Nushell: Introduction to a new kind of shell

#202
post #200
post #188

Please correct me if I'm wrong, but doesn't nushell suffer from the same problem as powershell that all the nice fancy stuff works only for in-process commands and external programs are bit of a second-class citizens? To me interesting question is that is it even possible to build rich strucure-aware shell-like cli environment that would allow seamless integration of external polyglot programs in the same vein as uni…

nushell seems to have better way of parsing the string-only outputs of other commands. https://www.nushell.sh/book/commands/parse.html I don't know how to do a similar thing in powershell. > To me interesting question is that is it even possible to build rich strucure-aware shell-like cli environment that would allow seamless integration of external polyglot programs... Problem is that most of the classic Unix progra…

> nushell seems to have better way of parsing the string-only outputs of other commands.

Yup. In addition to that `parse` command, Nu also has a suite of `from` commands that trivially convert other data formats to Nu tables. CSV, JSON, TOML, XML, YAML, and many more.

So if you're working with a program that can emit, say, JSON, you just do `some_external_command | from json` and boom, you've got a Nu table.

Re: Nushell: Introduction to a new kind of shell

#203

Earlier quoted context omitted.

> I may never write a bash script again I wrote 2x 200 line-ish shell scripts recently, and it was simply terrible, and although I'm increasingly convinced we need a shell like abstraction, I can't believe `bash` is the best we can do. Really hope I find one of these alt shells that suits me. Not a fan of Python but xonsh looks really cool too.

Bash is not the best we can do! If you want a traditional Unix-like shell that is mostly sensible in the places where Bash is not, check out Zsh. It has a ton of complicated features, but most Bash scripts can be ported easily (if not outright copied and pasted). Zsh has fewer footguns by default than Bash, and it has more "safety" settings that you can enable. There is also the Oil shell, whose creator often posts o…

Since I can't edit my post anymore, here are some additional thoughts:

Traditional shell scripting languages are great at exactly three things: typing commands interactively, running other programs, and sourcing other shell scripts. They are also is distinct in that they are "stringly-typed" (i.e. everything is a string), and moreover that syntactically bare symbols are also strings.

Typing commands interactively is essential because... it's a shell. That's what it's for. Most programming languages do not and should not optimize for this. But it's literally the purpose of a shell, so a shell should be good at it.

"Running other programs" includes invoking them (literally 0 extra syntax), piping them (one letter: |), and redirecting the standard input and output streams to files (>, "Sourcing other shell scripts" practically isn't much different from "running another shell process", except that source'd shell scripts can set shell parameters and environment variables, which is an important part of e.g. the X11 startup system: the global /etc/X11/Xsession script sources the user's ~/.xsession script, so any environment variables set in the latter are propagated to the former, and thereby are inherited by the X11 window manager when it eventually starts. If you wrote the /etc/X11/Xsession script in any other programming language, you'd have to inspect the environment variables of the ~/.xsession process and "merge" those values back into the current process' environment.

On being stringly-typed, I think it's mostly good in the context of the "two things that it's good at" described above. It cuts down on syntactical noise (otherwise "everything" "would" "always" "be" "quoted" "everywhere"), makes string interpolation painless, and generally supports the "typing commands interactively" use case. Make and Tcl are the only other popular languages in this category. Perl and Ruby allow it in specially-delineated areas of code. Moreover, Bash, Ksh, and Zsh all have arrays, which helps fix some of the biggest problems of everything being a string.

In short, if your program can make good use of the above features, then a traditional shell is a great choice. If you program does not need those features, do not write your program using a shell script, because shell languages are awkward at best in pretty much all areas.

And if you are considering an "alt" or "neo" shell language, in my opinion it must excel in the above two categories. Being stringly-typed is a matter of taste, but the language should also probably support bare-symbols-as-strings and string interpolation.

Python, for example, is not a good shell scripting language because it is not easy to type nontrivial commands interactively, it lacks tidy syntax for input/output redirection (even though it's actually pretty easy using the standard library), and it lacks bare-symbols-as-strings. So instead of:

    #!/bin/sh
    foo -x 1 -y 2 "$ABC" | bar --json -
you have to write something like:

    #!/usr/bin/env python3
    import os
    from subprocess import Popen, PIPE, run

    foo_cmd = ['foo', '-x', '1', '-y', '2', os.environ['ABC']]
    bar_cmd = ['bar', '--json', '-']
    with Popen(foo_cmd, stdout=PIPE) as foo_proc:
        foo_proc.stdin.close()
        run(bar_cmd, stdin=foo_proc.stdout)
You can of course write your own library that abstracts this and uses symbols like > >> base language Python is not a good shell, despite it being portable, being nearly ubiquitous nowadays, being relatively easy to use and learn, being "safe" in many ways that traditional shell languages are not, and having a huge and useful standard library.

Re: Nushell: Introduction to a new kind of shell

#204
post #200
post #188

Please correct me if I'm wrong, but doesn't nushell suffer from the same problem as powershell that all the nice fancy stuff works only for in-process commands and external programs are bit of a second-class citizens? To me interesting question is that is it even possible to build rich strucure-aware shell-like cli environment that would allow seamless integration of external polyglot programs in the same vein as uni…

nushell seems to have better way of parsing the string-only outputs of other commands. https://www.nushell.sh/book/commands/parse.html I don't know how to do a similar thing in powershell. > To me interesting question is that is it even possible to build rich strucure-aware shell-like cli environment that would allow seamless integration of external polyglot programs... Problem is that most of the classic Unix progra…

> It would be nice if we could agree that each command has --json flag (for example) which will make the output trivial to parse programmatically in any other advanced shell.

That's part of the solution, but I think a signaling layer of sorts is needed too so that the reading side knows that the data is structured instead of just bytes. So basically instead of needing explicit

    > foo --json | from json | ...
You could have

    > foo --json | ...
From there it would then be easy to have env var or something instead of explicit cmdline flag to eventually end up with (almost) seamless

    > foo | ...

Re: Nushell: Introduction to a new kind of shell

#205

Just was trying it. A couple minutes in, I discovered it doesn't support suspended jobs. :( seems like that would be a very basic feature. https://github.com/nushell/nushell/issues/1329 https://github.com/nushell/nushell/issues/1796 https://github.com/nushell/nushell/discussions/5239

You might be interested in Cat9, https://github.com/letoram/cat9

It's another reimagination of a shell, but built around asynchronous jobs

Re: Nushell: Introduction to a new kind of shell

#206

Earlier quoted context omitted.

> I may never write a bash script again I wrote 2x 200 line-ish shell scripts recently, and it was simply terrible, and although I'm increasingly convinced we need a shell like abstraction, I can't believe `bash` is the best we can do. Really hope I find one of these alt shells that suits me. Not a fan of Python but xonsh looks really cool too.

Bash is not the best we can do! If you want a traditional Unix-like shell that is mostly sensible in the places where Bash is not, check out Zsh. It has a ton of complicated features, but most Bash scripts can be ported easily (if not outright copied and pasted). Zsh has fewer footguns by default than Bash, and it has more "safety" settings that you can enable. There is also the Oil shell, whose creator often posts o…

I would recommend Oil!

http://www.oilshell.org/release/latest/doc/idioms.html

It removes the need to quote every variable, and this is fantastic

Re: Nushell: Introduction to a new kind of shell

#208
post #200

Earlier quoted context omitted.

nushell seems to have better way of parsing the string-only outputs of other commands. https://www.nushell.sh/book/commands/parse.html I don't know how to do a similar thing in powershell. > To me interesting question is that is it even possible to build rich strucure-aware shell-like cli environment that would allow seamless integration of external polyglot programs... Problem is that most of the classic Unix progra…

> nushell seems to have better way of parsing the string-only outputs of other commands. Yup. In addition to that `parse` command, Nu also has a suite of `from` commands that trivially convert other data formats to Nu tables. CSV, JSON, TOML, XML, YAML, and many more. So if you're working with a program that can emit, say, JSON, you just do `some_external_command | from json` and boom, you've got a Nu table.

Parsing JSON in powershell is not that bad either, `ConvertFrom-Json` pretty much does what you need. AFAIK there is nothing as convenient as nu's `parse`

Re: Nushell: Introduction to a new kind of shell

#209

Earlier quoted context omitted.

> I may never write a bash script again I wrote 2x 200 line-ish shell scripts recently, and it was simply terrible, and although I'm increasingly convinced we need a shell like abstraction, I can't believe `bash` is the best we can do. Really hope I find one of these alt shells that suits me. Not a fan of Python but xonsh looks really cool too.

Bash is not the best we can do! If you want a traditional Unix-like shell that is mostly sensible in the places where Bash is not, check out Zsh. It has a ton of complicated features, but most Bash scripts can be ported easily (if not outright copied and pasted). Zsh has fewer footguns by default than Bash, and it has more "safety" settings that you can enable. There is also the Oil shell, whose creator often posts o…

>If you want a traditional Unix-like shell that is mostly sensible in the places where Bash is not, check out

PERL. Sh, awk, sed and mini-C all at once.

Re: Nushell: Introduction to a new kind of shell

#210

Earlier quoted context omitted.

Why use this over PowerShell for example?

No need for (a minimal set of) dotnet runtime. This means Nushell can possibly run on slightly resource constrained environment such as Raspberry Pi, of course you don't expect it to run well with 256MB of RAM though. Also, Nushell is battery packed. For example, say bye bye to your Oh-my-ZSH because the features you have with OMZ (like shell autocompletion, suggestion, theming and formatting) is built-in in Nushell.…

>of course you don't expect it to run well with 256MB of RAM thoug

I've run Perl scripts on 32MB...

Post reply on HN