Oils Blog

+1 on nushell, it is incredible. Having all data typed and structured is an insane superpower.

Common worries I hear from people that were non-issues in practice:

- Not POSIX compatible: Nushell doesn't aim to replace POSIX, there's no problem with dropping back to bash to execute some shell snippets

- You need to re-learn everything: I'm not a huge fan of how the commands are organized, but I still didn't find it that difficult. nushell's prompt/readline comes with an inline help menu with fuzzy search. Hit CTRL+O to edit a command/pipeline in your IDE/editor of choice with LSP backed intellisense, type-checking and in-editor command docs/help. The syntax is very simple and intuitive.

- Just use python: Sure, but python comes with a lot of disadvantages. It's slow and uses dynamic typing. Static typing in nushell catch typos in pipelines & scripts before they execute. It also makes in-shell and IDE LSP tab-completions very accurate. Large files process quickly though it will still consume more memory if you aren't able to process all the data in a streaming fasion. It's like having jq but with autocomplete and it works on all command output & shell variables. Though if you really like python, check out Oil/OSH/YSH: https://oils.pub/

- All Unix commands output text, structured data is useless in a shell: `detect columns` (https://www.nushell.sh/commands/docs/detect_columns.html) - now it's structured. Or use `from <format>` if the command outputs CSV, JSON, INI, YAML,…

The context of the blog post is that "warts" are the way something was originally designed or built, which is now outdated and you would change it if you could, but you don't want to break backwards compatibility so you don't.

> "For example, some GNU programs like `grep` and `find` support a `POSIXLY_CORRECT` env var, which changes their interface and behavior."

By your own logic that's not a wart, that's the way the programs work and they are documented to work like that. Twisting yourself into knots to pretend Linux/Unix utilities are perfectly designed isn't good logic. There's no excuse "it was designed that way" or "it's documented to work like this" which makes something not warty. Something might have been a good design originally and become a bad design as the world changed around it.

For example unserialised byte streams where you have to fight whether \n or 0 (null byte) are data or record separators, is a wart. How do we know? Because when people design newer tools they don't keep that, they design it away. Serialised JSON and jq, .NET objects in PowerShell, structured data in nushell[1] and oilshell YSH[2].

[1] https://www.nushell.sh/

[2] https://oils.pub/ysh.html

??? This complaint seems more than 20 years too late

Arithmetic is built into POSIX shell, and it's universally implemented. The following works in basically every shell, and starts 0 new processes, not 2:

$ bash -c '[ $((1 + 1)) = 2 ]; echo $?' 0 $ zsh -c '[ $((1 + 1)) = 2 ]; echo $?' 0 $ busybox ash -c '[ $((1 + 1)) = 2 ]; echo $?' 0 YSH (part of https://oils.pub/ ) has a more familiar C- or JavaScript-like syntax:

$ ysh -c 'if (1 + 1 === 2) { echo hi }' hi It also has structured data types like Python or JS:

$ echo '{"foo": 42}' > test.json $ ysh ysh-0.28$ json read < test.json ysh-0.28$ echo "next = $[_reply.foo + 1]" next = 43 and floats, etc.

$ echo "q = $[_reply.foo / 5]" q = 8.4 https://oils.pub/release/latest/doc/ysh-tour.html (It's probably more useful for scripting now, but it's also an interactive shell)

https://github.com/shellfire-dev

https://github.com/shellspec

https://oils.pub/

There's probably more.

The shell has a ____wide____ userbase with many kinds of users. Depending on your goal, the rabbit hole can go very deep (how portable across interpreters, how dependant on other binaries, how early can it work in a bootstrap scenario, etc).

These are mine:

https://github.com/alganet/coral

https://github.com/alganet/shell-versions

https://github.com/Mosai/workshop