Hacker News new | ask | show | jobs
by Test0129 1330 days ago
> In a nutshell, nushell is non-POSIX shell, so most of your regular shells knowledge (zsh, bash, ksh, etc…) can't be applied on it, and using it feels like doing functional programming.

Is there a reason some shells like fish (and now nushell) are non-POSIX? What is the benefit? I really like fish but I've kept away from it because it's non-POSIX and won't necessarily play well with years of POSIX scripts and knowledge I have.

4 comments

Is there a reason every PL designer in the world didn't just make a new implementation of Pascal rather than design Python or Java or Rust? :)
Is there a reason some shells like fish (and now nushell) are non-POSIX?

Some things are different than other things. It's the same reason that not all desserts are pie, and not all automobiles are trucks.

I guess I was more curious about the cost/benefit. Given a well defined standard like POSIX, and the difficulty of swapping in a new shell into Windows, I wasn't seeing why you'd buck the well established trend.
fish = "friendly INTERACTIVE shell"

Fish is my daily driver. I use it because it makes things I do regularly either easier, more memorable, or less error prone.

The primary use for fish is not scripting, afaik.

From a quick glance, nushell, like powershell, is strong working with pipelines of not-just-text data. That's better for your scripting/automation needs.

[Rant: Afaik, POSIX standardized what people did and agreed on at one point in time, warts and all.

For example, whitespace is a nightmare... in sh, var=$value vs var="$value", look at warts like "$@" and the ever-present annoyance of handling of paths with whitespace. I'm not even going to go look to see what of these are mandated by POSIX. Multi-OS scripts are different, doing something like Oil (oilshell.org) or PowerShell makes a lot of sense... ]

Again, it's just because sometimes things are different. That's why I used pies and trucks as an analogy. Both pies and trucks are well established, serve their needs well, have plenty of variety, and room for improvement and innovation. That does not mean all work on desserts and automobiles should contain crusts and beds. Those are design decisions that serve some purposes very well, but not everything.

Most importantly: programming, like baking and automobile design, is an artistic craft, not just a solution to real world problems. We as a society already have well established solutions to tasty treats, transportation, and interacting with a computer. Trying something new will not harm anything, but there is a chance it may revolutionize everything. If it meets the authors requirements, while satisfying their creative urge, then the cost is well worth the benefit. Even if they are the only ones to ever use it.

That said, if you are asking why is it worth it for you or anyone else to invest their time into learning how to use it, that is a very different question, and I have no idea. I will not be using this any time soon, but I wish them luck, and I am glad that they are trying something new.

Benefit is a better syntax...?
On windows a command interpreter is just a console application like any other console application, you just run and use it, no "swapping" involved.
So is Unix.

xterm -e /usr/games/nethack

xterm -e /bin/sh

Correct me if I’m wrong, but doesn’t POSIX dictate a text stream as STDIN/STDOUT?

If my understanding is correct, this basically rules out any attempts to create richer CLI pipelines that necessitate other kinds of data interchange. IIRC this was one of the motivating factors in the design of PowerShell—though I don’t know PS well enough to say if it’s POSIX complaint or not.

Because POSIX shell syntax is an unreadable and dangerous mess.