The case for Nushell

Allowed: Release Announcement of a command-line program designed for scripted use (e.g. bash, bats, awk, jq, coreutils/moreutils)
Allowed: Tutorials on using shell languages or supplementary tools designed for scripted use
Allowed: Code review/help requests for shell languages or supplementary tools designed for scripted use
NOT Allowed: Announcement of a CLI or TUI program that is not designed for scripted use (Yes, your fancy Zsh plugin which pretty-prints the date and time using only builtins is very cool, but unless you actually want to discuss the code itself, please check out !commandline instead!)
NOT Allowed: Domain-specific tutorials that do not involve shell scripting as a core component (e.g. docker-compose, ansible, nix). If you really love one of these, I’m sure there’s a community out there ready to talk about them!
NOT Allowed: Code review requests for non-shell programming languages and configuration languages (e.g. Python, Yaml)

@starman@programming.dev · 3 months ago

The case for Nushell

@dotslashme · 3 months ago

There are tons av resources (scripts, guides, examples) that make up the backbone of a lot of IT departments.

If you’re setting a new organisation, you can chose to go with nushell, but then you have to accept that you either need to write all scripts from scratch, or you need to convert an existing script to nushell. If you put nushell into an existing department/organisation, then you face the same problem.

Before there are substantial resources to solve common sysadmin tasks in nushell, organisational adoption is unlikely due to the cost.