Fish shell | Hacker News Reader

Fish shell

fishshell.com

233 pointsgscott118 comments

So the massive drawback of fish is it's incompatible with bash (and other shells people use). If you're in fish, this is easily remedied because almost every machine has bash too. However, you can't expect another machine to have fish.

However, I just really like fish. I also live out of my own shell, and I don't spend much of my life remote-ing into other machines. When I do, my mind flips into bash just as easily as I flit from TypeScript to C#. To me, this is largely a non-issue, aside from when I need to work out how to set the `$SHELL` variable for a program that expects bash.

I agree entirely. I've tried zsh and other replacements, but I keep coming back to Fish. It's intelligent, loaded with features, and ohmyfish adds a lot.

No other machine I connect to has fish, but for my own machines, it's my top choice. Still, I write a lot of utility scripts in bash for the compatibility and it can be annoying when I copy a command and I know it won't work because it uses some unsupported syntax in fish. Every now and then, and it is rare, I switch to bash locally to run something.

> However, you can't expect another machine to have fish.

I can, because whenever I get access to a new machine I download and compile it!

Well lucky you, that you always get download-and-compile rights on any machine you access. Not everyone is so lucky.

About 98% of common POSIX shell usage is covered by fish, right down to identical syntax. (Not everything is.)

Biggest tip for fish switchers: set fish as your terminal's shell instead of changing your login shell.

> Biggest tip for fish switchers: set fish as your terminal's shell instead of changing your login shell.

That's an interesting idea - I will try that. This bit me recently when I used Migration Assistant to move from a Mac with Catalina to one with Big Sur; my login shell was still set to the path for fish installed via Homebrew, but none of those packages were copied over. I managed to hack around it by copying bash into that location so that I could reinstall Homebrew and fish to finish repairing things.

IMO it's worth it to avoid Relocated Items popping up after every update.

If you do this, you will probably also want to add `-fish` to Terminal's preference Profiles > Shell > Ask before closing (*only if there are processes...). This will prevent you from getting prompted when closing a Terminal tab with the default shell running.

what's the difference between the two for the non initiatives?

AFAIK, login shell can be thought of as the default shell anytime you start a shell.

By default your terminal program uses that, but most terminals let you override that to be something else.

I still fail to see a significant difference. Been using fish as my shell for perhaps 15 years.

Perhaps not having to run chsh on a new machine, which I have to run -h on to remember how to use ever few years.

The main advantage is that if you screw it up or an update borks the shell itself, it's easier to fix if it isn't your login shell. At one point I decided to set Elvish as my login shell, and it turned out to not function as a login shell. As in, won't start at all. Any time I logged in, it would just immediately exit, ending my session. Work doesn't allow us to have root access (annoying), so I ended up having to boot into single user mode to set my shell back. I've done a similar thing with bash and "set -e".

Being new increases the chances of doing something like that that breaks the shell. It's annoying to fix for those of us with experience, and extremely difficult to fix for those without experience. It gets even worse when you consider that some distros like Ubuntu don't set a root password, so you can't log into the root account without sudo, which requires your user to have a functional login shell. I wouldn't want a new user to paint themselves into a corner where the only way to get their desktop working again is to remember how to boot into single user mode or boot from removable media and mount their hard drive. Doubly so if their Linux desktop is their only PC; it's going to be really annoying if the only way to write removable media to boot from is the machine that's currently broken.

Hmm, fish is approaching twenty years old and supported login the whole time. But, bugs still happen I suppose. I always kept OS CDs and later flash drives around for glitches however. Have one an old one in the tin right now.

I just start fish from .bashrc:

https://github.com/pkulak/dotfiles/blob/master/.bashrc

I did that, but this makes it far more difficult to use bash if you need to.

To use Bash in such circumstances you just exit Fish via ^d or type exit. The bad thing about is you execute a Bash shell which uses resources. But with today's RAM even on a smartphone this wouldn't matter. The convenience and safety (to have a working default shell) is worth it.

You can use Fish on any system where Nix runs on, btw. For example, I use it on Synology's DSM.

I just type "bash".

My biggest drawback for fish is that there is no way to concatenate several commands inside a block that I know of.

In bash, I can run the following do the following, and the only ways I found to do this in fish are using several commands or calling `bash -c` with a subcommand.

```

(cat file_1; cat file_2 | grep something) | sort

```

It's simply a block, and fish specifies blocks with "begin" and "end".

    begin; cat file_1; cat file_2 | grep something; end | sort

(note that this is distinct from a "subshell", which has a separate environment and typically is more confusing than helpful. In this particular case it doesn't matter)

Same for me. And fish is so much nicer that I’m not willing to use a less ergonomic shell on the system I use 99% of the time for the benefit of having it act exactly like the 1% environments.

And FWIW, those 1% environments don’t look and exact exactly like my local system, where I have a nice prompt configured and there are lots of aliases and functions I use frequently. My local bash is nearly as different from my remote bash as my fish is from bash.

I really don’t get this argument. In my shell I don’t type scripts on the prompt.

I use fish most of the time as a shell, but I still write bash or even sh scripts, because fish is not installed on most systems. If you run a bash script from fish, it is still executed by bash (because of the shebang).

But one of the selling points of fish is (from their website, I am not a user) that it has sane scripting.

That point appealed me most. If I continue have to use bash for scripting, I wonder what fish provides over zsh.

I think fish's syntax is cleaner, though as others have pointed out, the incompatibility is often not worth it.

Even though it's "sane", I would say it's not "powerful". It's significantly less powerful than bash, e.g. there is a list of missing things here:

https://github.com/pirate/fish-utils/blob/master/README.md

The first one seems like one of the bigger issues: https://github.com/fish-shell/fish-shell/issues/159

I have a particular viewpoint since I'm writing a shell for scripting, and I wrote this FAQ. http://www.oilshell.org/blog/2021/01/why-a-new-shell.html#wh...

But I didn't come up with that list of issues, and I've only used fish a tiny bit.

#159 kind of works with the `string collect` mechanism, although it is indeed not very obvious, compared to bash:

    set file_contents (cat filename | string collect -N)

I understand that this is purely anecdotal, but I'm using fish for quite a long time, I've written a lot of tooling for myself in fish, and I agree that sometimes there are some things which are annoyingly missing from fish (like this multiline variable thing), but I would not say it makes fish significantly less powerful. And these things are sometimes fixed, too.

For me, the main thing fish provides over zsh is nice defaults. oh-my-zsh can be incredibly slow, and without it zsh does take a reasonable amount of scripting & setup to make it as "nice" to use (which is why oh-my-zsh exists).

I think their "sane" scripting is more about ux for writing short disposable logic (the type you write in a terminal), rather than more detailed/advanced/structured programming that you might save to a shell script file.

Bash/zsh walk the line of being usable enoughh for typing terse quick commands (terminal syntax) while also being complex enough for writing large scripts (programming language). They end up being imperfect at both.

Even something like

   # only test if the build succeeds
   ./build.py && ./test.py

didn't work in fish until recently. It used to be 'and' but they recently added && for compatibility.

I think redirects and possibly pipelines work differently in fish too, although I don't remember the details. I type those on the command line frequently. I occasionally use loops as well, though when it gets big I do put it in a file.

Redirects and pipes work as you'd expect. Loop syntax is different. The difference in subshell invocation is the thing that sticks out the most: $(cmd) vs (cmd) in fish.

It looks like all of these are the same

    echo hi > out.txt
    echo append >>  out.txt
    sort < stdin.txt
    ls /bad 2>&1 | tee out.txt

But here docs don't work the same way:

   sort <<EOF  # syntax error in fish

I don't really like the here doc syntax so I guess that is pretty good. The && issue is still there on my Ubuntu Bionic machine:

    fish: Unsupported use of '&&'. In fish, please use 'COMMAND; and COMMAND'.

ls && ls

The && syntax was added in fish 3, released in 2018.

Piping and redirects seem to just work, command substitution is always just parentheses with no $ in front. Process substitution is not magic syntax like in sh, it's just a command that reads from stdin, writes to a temporary file, and outputs the path to that file:

vim (ls -lh | psub)

I think this warning is actually harmful: Years ago, I read this argument about fish and it turned me completely off using it.

Only more recently have I really realised this never applied to 99% of my (most people's?) use-cases.

The logical step many people miss is that shebangs make the compatibility of the user's shell largely irrelevant: the only real compatibility concerns are the bash version or `sh` aliasing on the user's system.

e.g. making bash scripts compatible with current macOS systems (outdated bash version and bsd-ish non-gnu binaries) is a far bigger pain than any compat issues fish brings.

> Only more recently have I really realised this never applied to 99% of my (most people's?) use-cases.

every time someone asks "how do i accomplish X task on the command line" (witness literally thousands of Stack Overflow posts like this) the answer is in bash.

so, i say it applies to essentially every use case where you didn't already know how to do it.

I love fish, but the fact that every answer to your questions is written in another language and has to be translated affects EVERYONE.

> every time someone asks "how do i accomplish X task on the command line" (witness literally thousands of Stack Overflow posts like this) the answer is in bash.

I don't get this argument: The solution is to search for:

"how do i accomplish X task in fish"

This is what I do with xonsh.

Of course, the bigger point that is being missed is that when someone opts to use a shell like fish or xonsh, they're less likely to search how to do X! The reason they picked another shell is often because it is easier to use, etc. In the case of xonsh, it's mostly just Python. I do a lot more in it than I could do in bash, because I don't need to search the Internet for anything.

I've been using Fish as my primary shell for years. The vast majority of the time those Stack Overflow answers written for Bash work as written in Fish with no changes.

Occasionally you'll need to write the command substitution or command chaining in a different way, but once you get over the initial learning curve this is easy and pretty mechanical.

Very rarely I find some command that just doesn't work in Fish, in those instances it's easy enough to open the bash shell or throw it into a script file.

> every time someone asks "how do i accomplish X task on the command line" (witness literally thousands of Stack Overflow posts like this) the answer is in bash.

Those answers, imo, come in 3 forms:

1. Short simple bash commands that will work in fish

2. Overly clever "one-liners" that would be better as a script

3. Edge cases.

(3) is rare enough that I don't see it as a big enough hurdle to avoid using fish.

> The logical step many people miss is that shebangs make the compatibility of the user's shell largely irrelevant: the only real compatibility concerns are the bash version or `sh` aliasing on the user's system.

It's a huge problem if you have stuff that is expected to be sourced into the shell rather than executed as a script., for example, because the sourced stuff provides a large API of functions.

In my experience, the only time I do this is with files that have been provided explicitly for my shell of choice.

The only exception to this that I see regularly is shell installers auto-adding some directory to the PATH env by making automated changes to bash/zsh confs in $HOME. This may be a slight annoyance for some, but tbh I like it as having to manually paste in a PATH addition myself allows me to audit them (and it's still quick enough).

> So the massive drawback of fish is it's incompatible with bash (and other shells people use).

This drawback is also its advantage, as it doesn't need to repeat all the Bourne-ish problems. (You seem to like this :-), just pointing it out for the others.)

I think people who are interested in how they use the command line will not have a problem to learn two shells, fish for the personal use and something Bourne-ish for scripts that might run on other machines, or by other users.

The Bourne shell certainly has problems, but IMHO fish should have stuck with POSIX syntax when it's "good enough" (TM). Stuff like $(code) vs (code) makes Fish feel like it just wants to be different.

Things I think are big problems:

* Needing to quote practically everything

* Needing to remember if/fi, case/esac, while/do/done, for/in/do/done, etc.

I run Fish on all my machines as well, and it's not like it's _that_ different from Bash. Maybe just for me, since I do not use either to write actual scripts. Only thing I notice on the command line is not using a dollar sign before open parens.

I find fish is a comfortable interactive shell and dash is a performant script-running shell. Bash is in the middle.

I really like this combo:

1) Use fish interactively, with quite a few aliases.

2) Write <= 10 line scripts in sh, perhaps with a bashism if it is very helpful, and only run on my machine.

3) Write > 10 line scripts in Python.

If all you do is copy paste other people's bash command than sure, stick to bash. The 99% of the time you're doing that you can use fish.

There is no need to change `$SHELL` :-/ you can use Bass (https://github.com/edc/bass) to execute any bash script and it will apply the environment variables to the current fish environment.

Bass has never worked for me. I'm not even sure if it has worked for me once.

Nit: Fish Shell is a bit redundant, as Fish stands for "Friendly Interactive Shell".

Now that's out of my system, fish is fantastic and made me realise importance of sensible defaults. I tried zsh but configuration took longer than I would have liked, and oh-my-zsh is too bloated to start instantly.

Compared to that, I have practically 0 modifications in my Fish config, apart from few aliases. I don't use fish for more than one-liners, and I never intend to. It is a very nice very fast and very lightweight way to interact with my system, which I believe was the original point of Shells in general.

Either way, glad to see it on frontpage.

I could not agree more, I'm sure zsh can do everything fish can and a lot more, but getting it to that stage would take me more time than I'll spend interacting with fish for the next few months

> Nit: Fish Shell is a bit redundant, as Fish stands for "Friendly Interactive Shell".

Isn't this a common trope with software e.g. "WINE is not an emulator" or people saying "ATM Machine".

Your first example is a recursive acronym (actually a backronym in this case), and is deliberate. That's the trope. Redundancy is usually just incorrect but common use of natural language.

Edit: I'm wrong about WINE being a backronym, but it is a recursive acronym.

> Redundancy is usually just incorrect

How is it incorrect?

Perhaps a weaker way of putting it is that it is colloquial, but not proper form.

> not proper form

Which is annoying to those who value form more than function.

Sure. I don't have an opinion one way or another and almost certainly "misuse" acronyms.

RAM memory

DVD disc

LCD display

We like our nouns to be general, and rather turn the acronym into an adjective. It makes good sense too: PROM memory, BluRay disc, OLED display show their connections

It is, and "RAS syndrome" (redundant acronym syndrome syndrome) should be encouraged, not avoided.

"PIN number" is easier and faster to understand. Probably better understood than "PI number" or the expanded form. And in this case, a link just named "fish" would have been fairly ambiguous.

It is a bit redundant, but that's not the same thing as saying it's bad or author should have eliminated this redundancy. I think of this a bit like a Checksum, which is also a redundancy... it reduces cognitive load/likelihood of error by the reader when parsing this particular acronym. Like ATM can mean both "At the moment" and "Automated Teller Machine", saying "ATM Machine" helps disambiguate (in a way) which acronym you mean. Often context is enough to do this, but as a habit/affordance to users with variable levels of familiarity with the context, I think it's a useful and good redundancy rather than a wasteful one to be eliminated.

Any medium of human communication (text, speech, body language, etc...) is lossy. Humans need acknowledgment, retransmission, and redundancy.

I’m not sure if I would click on a HN link that said just “Fish”. But Fish is great.

https://en.wikipedia.org/wiki/RAS_syndrome

No. This is not RAS. It's a continuation of a long trend in *nix/FLOSS for using recursive acronyms. One of the earliest:

GNU: GNU's Not Unix

The one closest to me (though I didn't invent it): JACK - the JACK Audio Connection kit.

It is. See the difference:

GNU Operating System -> GNU's Not Unix Operating System

Fish Shell -> Friendly Interactive Shell Shell

One expands to include the original acronym, but doesn't duplicate the descriptive extra words. The other doesn't expand to include the original acronym, but does duplicate the descriptive extra word.

In other words, one is recursive but not redundant, the other is redundant but not recursive.

What about bash shell? Bourne Again SHell shell. That's the same thing. But i think it can be a helpful distinction between using bash shell as an interactive shell and using the bash scripting language.

Yup. I'm one of those folks who thinks that RAS syndrome is an entertaining and occasionally useful language quirk, and not at all a problem.

For example, even within a computing context, saying "Fish shell" just might help someone understand that you're talking about the Unix shell and not the cipher, and would always help someone who's not familiar with Fish to at least understand that you're talking about an alternative Unix shell.

By contrast, whenever someone posts a Hacker News article about ML, the first comment is invariably someone complaining that they thought it would be about machine learning, and this is unnecessarily confusing, and a borderline injustice, it should change its name, etc. It would probably be easier for everyone involved if it were idiomatic to say "ML language", even thought doing so would be redundant.

But ML preceded ML (at least as a somewhat widespread topic of discussion), so it's the machine learning fans who get to come up with alternative terminology.

They could have written "Fish the shell" to disambiguate from "fish the animal" and nobody would have complained. But they left out "the", and now it's redundant?

Isn't it funny how the mind works?

I disagree that it's actually redundant. It's like if back in 2004 somebody said "Apple computers are overpriced and underpowered." Technically, "Apple" in that sentence stands for "Apple Computer," so you're saying "Apple Computer computers are overpriced and underpowered." But that's fine, because it's just part of the company's name, not actually a redundancy. No copy editor would have flagged that, but they would have flagged attempts to remove the redundancy by saying things like "Apples" or "Apple Computers." Similarly, Fish is a name, so adding "shell" is useful in identifying the thing you're naming.

a good friend of mine used to say NIC Card Card

I love Fish, I've found it super easy to write small helper utilites for working with virtualenvs or opening Sublime projects. The barrier to scripting is so low and the language so approachable that if I have an idea for a new function I'd like to write, I can get it working in < 10 minutes almost every time. +1 to all the comments about `abbr` for abbreviations, makes working with Git great since I can still tweak the command before if I need to before it runs, plus it helps me remember what the command actually is instead of just setting & forgetting like with an alias.

+1 for scripting.

I wrote so many more small scripts for myself. Since I didn't need to consult a syntax manual every, the friction was low.

I switched all my home machines' shell to fish, and my work computer also to fish, and it has been an amazing productivity boost for myself. The extremely ergonomic way it represents history (old commands) is what does it for me.

If I need to script something, I always do it in bash (which is easy to transition to from bash). I don't use the fish language for any scripting because of incompatability, but as a command line interface to my systems it has been a massive boom to my quality of life. I could not reccomend it more.

> I always do it in bash (which is easy to transition to from bash)

Did you mean dash?

I love Fish, pairing it with Starship prompt (https://starship.rs) makes a truly powerful combo with almost no extra config necessary.

Thank you for showing me this; the ZSH starship prompt is what has prevented me from going back to Fish, but now I have no such excuse!

Add ranger to that, it’s a very simple and lightweight TUI file manager

Previously: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...

This shouldn't be downvoted. I don't think that this person is necessarily complaining that it was reposted; rather it's sometimes nice to be able to go back and see previous discussions.

Exactly, thanks. There's plenty of gold in those old threads.

I've been using fish for about seven or so years now. I've read a lot of people complain about the POSIX incompatibilities, and while I agree that that used to be a relatively annoying issue at first, most of it is not a problem in newer versions of fish (missing && was annoying, for example).

The fact the syntax diverges from bash/zsh is IMO a great boon to fish. I've enjoyed writing fish scripts much more than zsh/bash scripts.

At work I write both for things that runs on dev machines, since I converted a lot of colleagues to fish, and writing the bash/zsh ones is usually not that much effort to write.

Sure, it's a bit of a maintenance burden in theory, but it's not become a problem in practice yet. A few times I had to wonder "how do I sensibly do this in bash/zsh" when it was pretty friction-less in fish, but it hasn't happened often.

Another thing regarding compatibility: I've never had it be a major problem when things _truly_ were incompatible, since as others in the thread mentioned, I could just do `bash`, run the script and then CTRL-C.

I love Fish. Here's my list of essential plugins:

- jorgebucaran/fisher (plugin manager)

- IlanCosman/tide (prompt)

- jhillyerd/plugin-git (git abbreviations)

- PatrickF1/fzf.fish (history finder, and other autocompletion)

- jethrokuan/z (directory jumping)

- jorgebucaran/autopair.fish (auto-complete quotes)

The auto-complete experience is what I like most about Fish, followed by abbreviations (not aliases) auto-expansion.

My FISh setup:

Fish + oh-my-fish + theme-bobthefish + powerline modified fonts

One of Fish’s features I like the most is a per-directory command history stack, on top of the normal history stack.

> a per-directory command history stack

I’ve used Fish for years and always suspected it offered command history by directory. Fish really “just works” so I never felt the urge to investigate and verify my suspicion.

It also seems to have a type of per-command history. As you begin to type the command, you can tab through and auto-complete other similar commands you’ve done.

I did myself a favour, and instead of learning a new shell read through grymoire's POSIX shell tutorial: https://www.grymoire.com/Unix/Sh.html.

I'm a fish user for over 10 years now; for me a big part of the appeal of fish was (and still is) that I could get a much better quality of life without having to train myself to wizard-level with the less ergonomic but ubiquitous bash. I'm sure any black belt bash wizard will leave me in the dust on every metric, but that's fine, I don't need my shell environment to be super optimized for maximum effectiveness, it just has to be good enough to do my work and get out of my way. Fish does that very well for me.

+1 for this. Fish is kinda like the Emacs of terminal editors in my mind: it's more dependent on keybindings than it is command invocations.

I definitely agree with you, it's just not worth struggling with something you don't like.

For me this was vim. After struggling for many years with this ancient and difficult text editor peddled as the holy grail of productivity one day i just said fuck it and switched to a more sane text editor called nano. My life became instantly better and I've never looked back.

I really wish I made the switch earlier instead of suffering through the never ending annoyance of vim because i at the time I thought i was still learning it and one day it will all be worth it.

I'm glad that you are happy with your setup. Every one of us is so special that there could be no one size fits all solution. The reason I started going back to bash and to some extent POSIX shell is a simple question which I nowadays ask myself: do I know why I am using this? or: do I _really_ need this? When I lack a strong reason for picking up something, I drop it, and when I can live without learning a new tool, I do it.

Fish is fast but the thing which stops me from keep using it is that fish is not POSIX compliant. so I just use zsh for interactive shell and dash for scripting (and use bash when dash is not enough).

It's easy to configure zsh to be mostly like fish. Here is my zsh setup, I don't use any zsh framework, just install them with my package manager and source related plugins in $HOME/.zshrc.local (except powerlevel10k which I need to clone the repo and source powerlevel10k.zsh-theme)

- grml-zsh-config[1]. lots of useful base stuff

- zsh-completions

- zsh-autosuggestions. fish-like autosuggestions

- zsh-syntax-highlighting. syntax colors

- fzf-key-bindings.zsh / skim-key-bindbings.zsh. fuzzy file/history search

- powerlevel10k. fancy prompt

[1] https://grml.org/zsh/

Favorite feature of Fish shell is `abbr` abbreviate. Which expands the abbreviations after <enter> or <space> allowing it to reveal the magic behind it, for screensharing/observability and for modification. I use it with --long-options too so the abbreviations are more self-documenting.

e.g. `abbr --add --universal -- gg 'git log --graph --oneline --all'`

I've been using fish for a year. I don't bash much, so that's a data point.

I really enjoy it. Faster than zsh once it's loaded with all the plugins that make it behave like default fish.

> Faster than zsh

Definitely, and it's noticeable.

> once it's loaded with all the plugins that make it behave like default fish

Fish also feels more cohesive in this situation; a case of built-in features being more refined due to being under the purview of maintainers and shipped to everyone.

>Definitely, and it's noticeable.

I've heard people say the same about zsh vs bash but when macOS updated I never even noticed.

Tried it, liked it, but the incompatibility with copy-pastable scripts online made me switch back.

If those little copy-paste sh/bash scripts would have worked, I'd still be on Fish.

What stopped you from writing "bash[enter]" before running your scripts?

Or running the pasted scripts through bash in fish?

I actually use this guy: https://github.com/edc/bass

I switched to fish in the last ~6mo, after bash for years. I feel like its made me more productive, especially the auto complete.

I have read a number of opinions concerned about the portability of fish. Perhaps, my own use case is different, but I have experienced very few compatibility problems.

The most common compatibility problem for me is copy pasting a shell command with `$(...)` in it. Switching to bash and re-pasting is pretty effortless, but this doesn't happen often.

Unrelated but the logo reminded me of some Internet culture. Way back in the AOL days where phishing was coined, hackers referred to phished accounts as <><. The little programs that spammed "I'm from AOL what is your password?" messages were called phishers or baiters and the programs that held hacked accounts and their password, or <><, were called phish tanks.

>” Finally, a command line shell for the 90s”

I had a good laugh when I read the title of the website praising to be modern 31 years ago.

The problem with these alternative shells (to me) is that you'll have to install the shell on other machines before you can use the script you wrote. Bash being present on just about all Linux distros makes it useful, even if the scripting is quite terrible. And if I'll have to do something more complicated I'll use a proper scripting language like Python instead of learning another shell language.

It would be great if bash was a little less crap though.

I personally don't use the scripting language at all (except for configuring it or whatever). I just use it as a nicer bash interface.

Yep. I use bash for scripting, but fish for general terminal usage.

I think my biggest annoyance using fish daily for years is with certain string subcommands just barely not having enough power to replace sed/grep/awk usage in bash scripts but that's been improving.

I find it so much easier to quickly throw together a function or a script for whatever random task I want to do in fish than in bash and actually have confidence that it'll work without tons of trial and error and needing to look up syntax.

Anyone using fish in Vim mode? Does it work well?

Last time I tried I had not such a good time. Would love to see a tutorial on how to use it efficiently.

I always wondered why anyone would do this. IMHO modality and shells just don't get along well. Besides that, readline-like bindings are both good enough and you're likely to encounter them in the wild when working with ssh, database prompts, and so on.

Yep, what kind of issues you had? Works well for me. Not sure what do you mean by efficiently -- but my tip is pressing alt-e to edit the command in external editor when it's multiline (although it's not limited to vi mode in fish)

It interacts pretty poorly with, e.g., terminals in IDEs, but is essential for my day to day in my regular terminal emulator. Worth noting I'm not a vim power user, but I could live without vim keybindings for moving around, it just feels more naturally.

I have tried vim mode in fish and I didn't like it. I find I don't really need vim bindings in the shell because I'm almost never editing. Alt+e to open the current command line in my editor works really well for me when I do want vim.

In case you were wondering, here are some people who are either slightly amused or just as confused [1].

[1] https://twitter.com/search?q=a%20command%20line%20shell%20fo...

Most of them were unable to voice any concerns beyond mocking the outdated motto. It seems like these people are clueless.

I really like fish shell. After ditching bash and picking up ksh for its much nicer array notation, I needed a frontend shell, and it really fits the bill. Its defaults are really friendly, and it is very configurable.

For Shell Scripts use F# ;) https://twitter.com/adelarsq/status/1390459435194241025

I've been using fish for years and adding fish bindings to ROS remains my biggest open source contribution. It's a joy to use.

In case others don’t know, I recently learned that Python virtual environments will install an activate.fish script :)

I tried it on my mac but all the paths are underlined like hyperlinks and it's strange. I'm using iterm2

Fish's highlighter highlights valid paths with the color specification given in $fish_color_valid_path. By default that's "--underline".

If you don't want it, set the variable to empty with

    set fish_color_valid_path

If you command-click on them, they are links

Personally, my favorite shells are Ipython, Ammonite, and JShell.

Well, I guess it's a fish shell

Reply on news.ycombinator.com