Live data from Hacker News

Nushell: Introduction to a new kind of shell

dataswamp.org

161–170 of 252 posts

Re: Nushell: Introduction to a new kind of shell

#163
post #141

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

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.

Re: Nushell: Introduction to a new kind of shell

#164

Having 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…

Wouldn't 'find .. -exec ' and friends get you this?

    find . -type f -depth 1 -exec ls -la {} + | awk {'print "file="$9 " user=" $3 " group=" $4 " size=" $5'}

Re: Nushell: Introduction to a new kind of shell

#165

I just ported a bunch of scripts to nushell. I hit some bugs, a couple of which are a bit sharp, but wow, the list of quirks I have to remember for nutshell are so much fewer than for bash. Constantly impressed at the errors it catches at parse time, kinda crazy sometimes. Oh my god I could cry, strings are sane to work with. I may never write a bash script again (it's okay, I use Nix so I get nushell everywhere I'm…

> 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, but it is definitely the best that most people agree on.

I fear there will be no defacto bash replacement for many years.

Re: Nushell: Introduction to a new kind of shell

#166

Earlier quoted context omitted.

Why use this over PowerShell for example?

I am a C# programmer at heart, and I use powershell a good bit. I can honestly say I can never use powershell without my cheat sheets or my list of favorite commands (and especially the arguments to use). I looked at this and kinda get it and think I could do some things with it. I don't think it's as powerful and can _definitely_ say it won't be capable of the same automations we use. That said, the text parsing peo…

> can _definitely_ say it won't be capable of the same automations we use.

Anything in particular you think would be difficult/impossible in Nushell?

(I'm one of the Nushell developers, might be able to help or put features on the roadmap)

Re: Nushell: Introduction to a new kind of shell

#167

Earlier quoted context omitted.

> ArentCamelCaseMonstrocitiesOnlyMicrosoft --CouldLove Personally, CamelCase makes more sense than everythinglowercasesmushedinto -onetwothreefourparametersSometimesCapitalised and --sometimesdoubledashed and -Isometimesspacedoesn'tmatter -and --sometimes - "dashlivesalone" --AND -o -- "twodasheslivealone".

Not having used nushell, is that what it is like?

nushell is like most POSIX shell - terse.

   ls | where type == file

Re: Nushell: Introduction to a new kind of shell

#168
post #11

Previous discussions about Nushell ( https://hn.algolia.com/?q=Nushell ), for example: https://news.ycombinator.com/item?id=27525031 (763 points | 1 year ago | 398 comments) https://news.ycombinator.com/item?id=20783006 (1477 points | 3 years ago | 366 comments)

Thanks! Macroexpanded:

Nushell 0.60 Released - https://news.ycombinator.com/item?id=30772042 - March 2022 (40 comments)

Nushell: A New Kind of Shell - https://news.ycombinator.com/item?id=30718349 - March 2022 (8 comments)

Nushell – a new type of shell written in Rust - https://news.ycombinator.com/item?id=28968966 - Oct 2021 (3 comments)

Nushell 0.38 - https://news.ycombinator.com/item?id=28841901 - Oct 2021 (1 comment)

GitHub – nushell/nushell: A new type of shell - https://news.ycombinator.com/item?id=27525031 - June 2021 (398 comments)

Nushell: A New Type of Shell - https://news.ycombinator.com/item?id=26712741 - April 2021 (2 comments)

Cbsh – a couchbase shell in rust on top of nushell - https://news.ycombinator.com/item?id=24767244 - Oct 2020 (4 comments)

One Year of Nushell - https://news.ycombinator.com/item?id=24259914 - Aug 2020 (47 comments)

Nushell – A New Type of Shell - https://news.ycombinator.com/item?id=22880320 - April 2020 (37 comments)

Nushell – a modern shell written in Rust - https://news.ycombinator.com/item?id=20845584 - Aug 2019 (4 comments)

Introducing nushell - https://news.ycombinator.com/item?id=20783006 - Aug 2019 (366 comments)

Re: Nushell: Introduction to a new kind of shell

#169
Does anyone have an ELI5 for what this, BASH, ZSH, Powershell etc do? It seems it's a conflation of #1: A CLI. #2: A specialized programming language that mainly does file-system operations. Is there a compelling reason to use something like this (or Powershell's scripting system, from the comments here), vice Python or Rust's etc standard library filesystem tools?

Context: I use Windows Terminal with embedded powershell on Windows, and Terminal on Linux. Useful for compiling programs, running Python scripts, and executing CLI-based programs (eg clippy, ipython, rust, various programming-language-specific formatters etc, some CLI-based text editors like VIM). Also, troubleshooting Linux problems.

Re: Nushell: Introduction to a new kind of shell

#170

Having 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…

Calling an external too to list files is an anti-pattern; every programming language or shell language should have that built-in, so it's just doing that via the OS API (opendir/readdir/closedir).

The POSIX shell has that in the form of globbing. That only gives you names, and has quirks that are only adequately worked around with Bash options.

The fix is to use some real programming language for complex work.

I made a language for myself in this space, geared toward C and Unix people who are willing to try Lisp: TXR.

  1> (stat "/usr/share/dict/words")
  #S(stat dev 2306 ino 884986 mode 33188 nlink 1 uid 0 gid 0 rdev 0 size 931708
          blksize 4096 blocks 1832 atime 1667315034 atime-nsec 0 mtime 1238396423
          mtime-nsec 0 ctime 1405615444 ctime-nsec 0 path "/usr/share/dict/words")
  2> (flow "/usr/share/dict/words"
            stat
            [callf list .path .size])
  ("/usr/share/dict/words" 931708)
  3> (flow "/usr/share/dict/words"
            stat
            [callf list .path .size [chain .uid getpwuid .name]])
  ("/usr/share/dict/words" 931708 "root")
Post reply on HN