Add support for && and ||

[LandonSchropp]

Thanks for creating such an awesome shell! I've been enjoying using it, especially when scripting.

I'm using Fish 2.7.0 on macOS 10.13.2 inside of a custom tmux terminal profile.

I'd like to request you guys add support for the && and || operators. I know fish supports and and or, but using them feels a bit awkward, especially with the required semicolon.

Going off of the Fish Design Document:

• The law of orthogonality: My suggestion is a violation of this rule. There's no way around that other than the idea that it's syntactic sugar.
• The law of user focus: I don't know about anyone else, but I expected these operators to exist when I first used Fish. They're almost universal across other languages and shells, and they're the first thing I reached for. I realized that's a sample size of one, but I wonder if other people expect the same thing. The use of ; also requires the user to understand that and is a command, which adds a bit of cognitive load.
• The law of discoverability: When I type && in a command, Fish prints out an error message telling me what I should have used and instead. However, I wish would just do what I wanted instead. This feels like when I type brew update <app>, and it tells me I should have typed in brew upgrade <app>.

I realize this is a small thing, but it's something I've missed from zsh.

[anordal]

Thank you for doing your homework on fish design before suggesting this.

This was suggested in #150, but that issue is "locked and limited to collaborators", which is the equivalent of keeping our ears shut.

Firstly, I think it's fair to ask how much the argument of "less syntax" holds true anymore after the fix for #1583 – this is not just syntactic sugar, but command-grouping syntax. When and and or were pure commands, this was a meaningless construct (and a schrödingbug):

if true; and false
    echo '↑ Where does the condition stop and the if-body begin?'
end

Basically, fish lacks a then keyword to if/while. To kill this gotcha, the meaningless construct was assigned the right meaning by changing the parser. It could also be solved with command-grouping syntax like &&/||, which would also look the way it works.

Secondly, I think this is one of the costlier incompatibilities. For one thing: ssh-copy-id (#2292). Another (personal annoyance) is Gerrit; its "cherry-pick" button puts a command like git fetch && git checkout <sha1> into your clipboard.

That said, for those coming here wanting full POSIX compatibility: Sweet dreams. POSIX incompatibility (aka. not having to quote variables) is reason alone to use fish.

[mvolkmann]

I am not a fish collaborator and I like the current design; I like how everything in fish is done with commands and how the “or” and “and” commands (not operators) do something based on the status of the previous command. The semicolon is just a way of stringing commands together.

…

--- R. Mark Volkmann Object Computing, Inc.

On Dec 24, 2017, at 9:58 PM, anordal ***@***.***> wrote: Thank you for doing your homework on fish design before suggesting this. This was suggested in #150, but that issue is "locked and limited to collaborators", which is the equivalent of keeping our ears shut. Firstly, I think it's fair to ask how much the argument of "less syntax" holds true anymore after the fix for #1583 – this is not just syntactic sugar, but command-grouping syntax. When and and or were pure commands, this was a meaningless construct (and a schrödingbug): if true; and false echo '↑ Where does the condition stop and the if-body begin?' end To kill this gotcha, the meaningless construct was assigned the right meaning by changing the parser. Notice that it would also be solved by command-grouping syntax like &&/||. Or a then keyword to if/while of course. Secondly, I think this is one of the costlier incompatibilities. For one thing: ssh-copy-id (#2292). Another (personal annoyance) is Gerrit; its "cherry-pick" button puts a command like git fetch && git checkout <sha1> into your clipboard… — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[LandonSchropp]

Sorry for the repeat! I tried searching for || and && in the issues, but I think GitHub treats those as operators in its search. Also, thanks for taking the time to consider this. 😃

One of my favorite sections of the Fish design document states:

When designing a program, one should first think about how to make a intuitive and powerful program. Implementation issues should only be considered once a user interface has been designed.

From my perspective as a user, I'm thinking about this more in terms of what makes sense to me, and not what makes works for the parser. I realize there are practical considerations that need to be taken into account, so this might be a nieve view.

I think this issue for me is more the semicolon in the middle and less using symbols vs. words. The semicolon feels like an unexpected addition that's there to satisfy the fish compiler. Would it be possible to drop it? To me, the second example is how I would expect the syntax to work:

if foo; and bar
  echo hello
end

if foo and bar
  echo hello
end

As a side note, I'm totally fine with the idea of closing this issue if you guys have already considered it and want to move on. My suggestion is simply me quibbling over a small thing in an otherwise great language.

I'd also never dream of requesting full POSIX compatibility. Dropping POSIX support drastically simplifies the language, which is my favorite feature of fish.

Merry Christmas!

[Rush]

I've been a fish user for over a year now (I think!). I really enjoy user-friendliness of the shell on a daily basis (especially auto-suggestions) but when it comes to executing and running one liners too often I find annoyances like missing &&. Some of it is muscle memory ... I still write sh scripts for various things ... and some of it is tools which provide their own one liners which they tell you to paste into the shell.

PS. Another thing which I would sell my soul for is easy support of one liners like: for file in *.jpg;do echo convert $file ${file%.jpg}.png;done. Again, maybe muscle memory but I keep starting bash whenever I need to do something more complex than piping some outputs.

[anordal]

@Rush Because of the ${file%.jpg}.png part? Yes, that's what a user coming from bash would reach for (I've missed it myself), but let's be honest: Few people know about that feature, or are able to read it. I've seen python programmers writing bash scripts … the outcome is pretty much given: Abuse bash arrays in a way that accidentally works (split on . and select the fist array element accidentally by failing to use proper array syntax). My guess is that at least python programmers would feel more at home with fish: string join . (string split . 'a.b.jpg')[1..-2] png

[Rush]

Not sure about you but I mostly use shell for one liners. Longer scripts I prefer to write in node.js, Ruby or Perl. With all due respect, your string join example is not usable for a one liner for loop.

[davidawad]

you can add this partial functionality, I've added my own findings on this in the wiki, you can check that out here: https://github.com/fish-shell/fish-shell/wiki/Bash-Style-History-Substitution-(!!-and-!$)

[LandonSchropp]

@ridiculousfish Thank you!

[rumpelsepp]

This is so awesome, thanks!