New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for && and || #4620

Closed
LandonSchropp opened this Issue Dec 24, 2017 · 15 comments

Comments

Projects
None yet
@LandonSchropp
Copy link

LandonSchropp commented Dec 24, 2017

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

This comment has been minimized.

Copy link
Contributor

anordal commented Dec 25, 2017

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

This comment has been minimized.

Copy link

mvolkmann commented Dec 25, 2017

@LandonSchropp

This comment has been minimized.

Copy link

LandonSchropp commented Dec 25, 2017

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

This comment has been minimized.

Copy link

Rush commented Dec 29, 2017

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.

@floam floam added the enhancement label Dec 29, 2017

@floam floam added this to the fish-future milestone Dec 29, 2017

@anordal

This comment has been minimized.

Copy link
Contributor

anordal commented Dec 31, 2017

@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

This comment has been minimized.

Copy link

Rush commented Dec 31, 2017

@davidawad

This comment has been minimized.

Copy link

davidawad commented Feb 2, 2018

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-!$)

@ridiculousfish ridiculousfish modified the milestones: fish-future, fish-3.0 Feb 28, 2018

@LandonSchropp

This comment has been minimized.

Copy link

LandonSchropp commented Mar 6, 2018

@ridiculousfish Thank you!

@rumpelsepp

This comment has been minimized.

Copy link

rumpelsepp commented Mar 6, 2018

This is so awesome, thanks!

@thiagodemellobueno

This comment has been minimized.

Copy link

thiagodemellobueno commented May 2, 2018

@davidawad - your link no longer brings anything up, just an empty wiki page.

@faho

This comment has been minimized.

@nafg

This comment has been minimized.

Copy link

nafg commented Jul 31, 2018

@Rush why not use basename to strip the extension?

@Rush

This comment has been minimized.

Copy link

Rush commented Jul 31, 2018

@nafg in some cases yes, but not if you want an absolute path to absolute path

> basename /tmp/foo/bar.jpg
bar.jpg
@Linusnie

This comment has been minimized.

Copy link

Linusnie commented Nov 20, 2018

@thiagodemellobueno: It got renamed since then - the link is https://github.com/fish-shell/fish-shell/wiki/Bash-Style-Command-Substitution-and-Chaining-(!!-!$-&&-%7C%7C).

While this works nicely when typing out commands it doesn't work when copy-pasting, which has caused problems for me in some cases. Isn't there a way to simply make fish parse && as and?

@faho

This comment has been minimized.

Copy link
Member

faho commented Nov 20, 2018

@Linusnie: Wait for 3.0.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment