Hacker News Reader

Comment by robin_reala | Hacker News Reader

Apart from the other good stuff in this release, I think this will make a lot of things much easier:

fish now supports && (like and), || (like or), and ! (like not), for better migration from POSIX-compliant shells

Finally! Fish 2.x shows you a message along the lines of "use `and` instead of `&&`", which is infuriating - it clearly knows what I want to do, and refuses to do it. I love fish and use it as my default shell, but I'm glad to see the fish team take a few steps towards bash compat.

Just because a language knows what you mean to do and can give a specific error messagr doesn't mean that, in general, and specifically, the developers want to commit to supporting && as valid syntax forever.

Perhaps the language creators have plans for future syntax that would not allow what you want. Even if for now the language evidently knows what you mean from the error message.

In this specific case, the developers of fish apparently decided && was good to add.

That reminds me of the very specific nag messages I get from Python 3 when I don't write parens around parameters for print... do what I want already.

What does someone want if they write "bar = print foo,"? Is it the same if "print" isn't the built-in function?

Operator precedence isn't really a new concept, and Python relies on it in plenty other situations:

    bar = 1 + 1

I do believe Python made the right call, actually: print needed to be unified with functions, and dropping the requirement for parenthesis for function calls would have introduced so much incompatibility as to make the Python 2 -> 3 transition far more difficult.

But ignoring the legacy issue, there is a better way to do function calls, and it is ruby.

Didn't Ruby borrow it from Perl?

And lisp, just less parentheses

Haskell/ml/caml do it better than Ruby.

    f 1 2
    (f 1 2).thing

Here the parentheses are nothing special, they just hint precedence.

As opposed to

    f 1, 2
    f(1, 2).thing

Awkward special-case commas and parentheses.

What does operator precedence have to do with this? Ending a parameter list with a comma changes the output of the print keyword but not a function. Assignment statements can contain function calls but not the print keyword.

C style function calls are common, explicit, and consistent. Python adds the best combination of positional, variadic, and named parameters of any language I know. ML style has less punctuation and simpler grouping rules. Ruby has the weaknesses of both.

That usage doesn't get the weirdly specific error message though. It's only the Python2-ish statement that gets one.

What does someone want "print foo" to do if "print" is a different function?

What does someone want "print (1, 2)" to do if "print" is the built-in function? It prints a tuple in Python 2 and ints in Python 3.

I get that. So the Python 3 interpreter has to assume that when I say "print (1, 2)", I actually mean, print these two individual arguments.

If I say "print 'foo'" though, it recommends "print ('foo')", but doesn't go all the way to assume I actually meant that. There's a piece of code handling that special case that stops short of actually interpreting what I apparently mean.

The frustration around that was the original point.

In Python 3 there was an explicit decision not to support print as a statement, and rather as a function call.

You missed the point... that decision should have been made.

Though I've really grown toward the 'everything as a function' pattern that Fish is trying to do, this is definitely a step back in the right direction. I might even wish for `$()` to be supported as well to allow even better copy pastable oneliners from Bash.

I thought it was to be included in 3.0, there's certainly an issue on it.

Your quoting is a bit confusing, as "`cmd...`" and "$(cmd...)" are similar,, while backtick-dollar-paranthesis is just asking for trouble... ;)

I take it fish didn't / doesn't support either?

Fish uses parentheses for command expansion, so backticks aren’t supported and the dollar sign is only for variable substitution.

Fish just uses (cmd), no $.

Ah, which I guess is why no subshell support?

There are other ways to do subshells than using the same syntax, just that the Fish developers never did it, maybe because it's not requested enough. I think it's still the most annoying thing about Fish, and the most convincing reason to switch away again. I frequently drop into bash to do

    (cd subdirectory && command --that might.fail) && run --command-in-original-dir --only-if-subshell-succeeded

... and expect to still be in the original dir when it's done. Any solution in Fish using "&& cd -" at the end of a block AFTER a maybe-failing command is just wrong, and there seriously isn't any way except saving and restoring $PWD every time you want subshell functionality, or using "; cd -" and manually saving the $status, which is equally as frustrating.

There are some non-syntactic suggestions in https://github.com/fish-shell/fish-shell/issues/1439

Sorry for the confusion, I'm to used to `` as code style for markdown, forgot HN doesn't support it. I'm glad Fish doesn't support the backtick syntax :). Like others mention it just drops the dollar from a 'regular' parenthesis expansion.

This is absolutely thrilling! I often have to flip between bash and fish due to some archaic tools we wrote relying on bash in wierd ways, and the swap between how both handled logic like this was cumbersome. Glad to see one less potential reason my team won't use fish.

awesome! can't tell you the number of times I have slammed into this when copy/pasting.

I upgraded with homebrew to v3.0 but the && syntax still doesn't work, do I have to do something special to enable it?

Close your shell and open it (or run fish again). You’re probably still in the original fish 2.7 that had previously launched. fish --version should show 3.0.0 (edit: yeah, that’s not going to work).

`fish --version` showed 3.0.0, after brew update but without closing terminal, but `ls && echo finally` still didn't work. However, closing and re-opening terminal, it now works.

`fish --version` starts a new fish that prints _its_ version.

You were still running the old version, and `echo $version` would have told you.

Hah, oops, should have realised that.

Because you still run the old version as your shell, from which you run the new version merely to have it print its version.

Awesome! I remember bumping into the github issue over it but I guess I didn't read far enough (or maybe it was long ago) to see that they were finally going to support && and || instead.

That’s new? Suddenly I feel less guilty about dodging coworkers who have been trying for years to get other people to try fish.

But maybe now it’s getting closer to production readiness.

Fish uses (and still supports) `command1; and command2` instead of `command1 && command2` (and similarly for `||`/`or` and `!`/`not`).

The syntax is different, the semantics are the same.

The fact that it doesn't support your particular preferred syntax doesn't mean it's not production-ready.

> your particular preferred syntax

I think it's called POSIX.

You seem to be making some sort of argument, I just don't know what it is. Are you saying that fish is not production ready because it's not POSIX-compatible?

It's still not POSIX compatible, deliberately.

I‘m not switching to fish because of its lack of POSIX compliancy. This is a valid complaint.

It is!

But calling it "getting closer to production readiness" feels a tad insulting.

It's probably just a bit of snark, so it's not worth getting up in arms about, but it's not really friendly phrasing.

If you feel productive with your current shell, stick with it, it is definitely a performance hit when switching shells. That being said, if you have a weekend, go for it, I won't switch back.

It's 13 years old it's been production ready for a very long time. Using your preferred syntax != production ready.

looks like i'm switching back to it again from zsh

Oh yes

Reply on news.ycombinator.com