Hacker News Reader

Comment by jhasse | Hacker News Reader

Copy and pasted from another reply: "I still wish fish support && and ||, if only for the times when I copy and paste some one-liner off of stack overflow and have to rewrite it."

That and support for

    SOME_ENV_VAR=foo ./bar

(not having to prepend "env ") are what's stopping me from recommending fish to others.

Btw: Big thank you for fish, it's awesome!

View on HN

I really like that you have to use `env` in fish, since it's cross-shell - it works in bash/zsh/dash/whatever. The `A=b foo` syntax is an unnecessary appendix in the syntax that complicates matters while only saving 4 characters.

I agree and think the best fix would be if the syntax would be forbidden in bash/zsh. Problem is: Millions of code snippets on the Internet not using env.

For one-liners, typing `env ` before pasting is likely not too much work. For longer scripts, you'd have to rewrite much of the text anyway.

often there's stuff like

    cd build && LD_LIBRARY_PATH=../lib ./foo

It's no dealbreaker though, I still use fish and love it :) Just a minor annoyance ;)

That syntax is from very early days of sh itself (predecessor of bash), IIRC. So removing it would break many scripts, as sibling comment by jhasse said.

It's not just to save typing - having an `A=b foo` form built-in instead of relying on an external program means `foo` can be an alias or shell function.

Agree with these, and would like to add one more:

  $(subcommand)

as an alternative to

  (subcommand)

PS: I have been using fish as my primary shell for about a year now, very happy with it. :)

Good news: Another dev mentioned that they are already discussing this: https://news.ycombinator.com/item?id=15913358

Yes please, even if we have to opt in to this behavior with a patronizing env var :)

Reply on news.ycombinator.com