Hacker News Reader

The best part about fish is you don't have to configure it much to be productive in it. It is really nice that the fish maintainers think hard about what should be configurable, and what sane defaults should be. This is not as common as it should be in OSS. Contrast with zsh, which has a billion knobs to tweak, and the consensus is that everyone should install a huge "community dotfile framework" (whatever that means) consisting of tons of opaque aliases and settings, some of which might make your shell startup lag.

More to a specific point: I haven't had much of an issue with fish's subshell/backgrounding control. That doesn't mean that there aren't issues, just that my interactive use doesn't trip into them.

I will note that you can write an async git prompt using nothing but fish itself, which I consider an advanced use case for a shell. Check it out:

https://github.com/mattgreen/lucid.fish

I ended up implementing my own background process management for fish here, it uses bash to fork a subshell with fish inside of it, which seems to solve all the problems I encountered.

https://github.com/pirate/fish-functions/blob/master/backgro...

https://github.com/pirate/fish-functions/blob/master/progres...

https://github.com/pirate/fish-functions/blob/master/signal....

https://github.com/pirate/fish-functions/blob/master/fork

Usage:

    background progress_await compiling_task_finished

    g++ ... some slow command

    signal compiling_task_finished

This allows the progress bar to truly run at the same time as the g++ command and receive a signal from the fg process when it's time to complete, something a simple & does not let you do in fish.

I've collected more details on Fish's issues here for anyone interested:

https://github.com/pirate/fish-functions#issues-with-fish

I like your semaphore idea a lot! Might be a good primitive to put in fish.

and if you need to configure something, it actually has a really pleasant ui that can be called with `fish_config`.

Very true. I have been using fish for the last five years without really learning the shell. The auto-complete itself feels so good and makes me productive.

Confession: I haven't taken pains to learn any shell after that. Almost similar to why I never took to try out VSCode after getting used to Sublime Text. So many demos, videos etc. quite tempt me to try out VSCode but still haven't ever got to it)

The only thing that I took note was to install https://github.com/oh-my-fish/oh-my-fish every time I setup a machine.

Would be great to know of any quick to learn fish-hacks or fish-for-dummies resources

Most common bash/zsh syntax works in shell. For most day to day shell usage, I'd say:

* get comfortable with stdin/stdout/stderr syntax (and redirection)

* get piping down pat. It's so useful.

* practice using &&, ||, and ; to sequence commands

* know how to use ENV=value to override env vars, and understand how env vars work

* yak shave a bit and make some aliases/functions in your shell based on your usage patterns

From here, it gets esoteric pretty fast, no matter what shell you're in. But you have enough concepts to figure out you need from there.

As for zsh, I partially agree, but you don't need to go with something heavy like oh-my-zsh. I use prezto, and it's great.

Fish functions are just gorgeous, and what made me drop Zsh like a hot potato. Suppose you want to make an automatically loaded (that is, not defined in the shell's rc file) function called foo. Here's how you do it:

- Make a file named ~/.config/fish/functions/foo.fish

- Inside it, define a function named "foo"

That's it. Now when you open a new shell and try to run the command "foo", Fish will look for the file named foo.fish in that directory, load and execute it, then call the foo function from in it.

Now, create an autoloaded function in Zsh or Bash without looking at a man page.

There are a million little niceties like that where I'd assumed that a certain task had to be complicated because every shell I'd used before had made it complicated, but then Fish came up with a nice convention for making it simple. Want to make a function to dynamically set your shell's prompt? Create a function named "fish_prompt" in the file ~/.config/fish/functions/fish_prompt.fish. Ta-da - turns out it doesn't have to be a pain in the neck to do that.

I completely agree about using it as a scripting language, though. It's great for making functions for your interactive shell, but stick with sh or bash (or Python) for writing more sophisticated stuff.

  for fname in $(ls ~/.config/zsh/functions); do source $fname; done

:)

for fname in ~/.config/zsh/functions/*; do source $fname; done

will prevent issues with special chars and spaces in filenames

When are you going to run that?

GP is talking about JIT loaded functions: 'that is, not defined in your shell's rc file'.

That’s the exact opposite. That’s eagerly loading all defined functions. autoloading means the function isn’t loaded until it’s used.

> Now, create an autoloaded function in Zsh or Bash without looking at a man page.

For zsh:

- Make a file named ~/.config/zsh/functions/foo

- Inside it, define the body of the function for foo

- Add ~/.config/zsh/functions/foo to $fpath with "fpath+=~/.config/zsh/functions"

- Declare foo with "autoload -Uz foo"

> Want to make a function to dynamically set your shell's prompt? Create a function named "fish_prompt" in the file ~/.config/fish/functions/fish_prompt.fish. Ta-da - turns out it doesn't have to be a pain in the neck to do that.

To do the same in zsh:

- define a function (can be autoloaded or not) named prompt_foo_setup to change your prompt

- add the following to your zshrc: "autoload -Uz promptinit; promptinit"

Now you can easily change to your custom "foo" prompt by running "prompt foo".

There are many valid points which make zsh (or bash) hard to use out of the box, but neither of the points you've raised are one of them. One can easily do both without "looking at the man page."

> One can easily do both without "looking at the man page."

How do you know which flags to autoload to use without reading the docs? How did you know to call autoload?

Oh please. The exact same thing can be said for fish. How did the parent commenter know to create a file named ~/.config/fish/functions/foo.fish? How did the parent commenter know to define a function inside that file?

The point is, it's trivial to create an autoloaded function in both fish and zsh. You don't have to look at the man page each time, which is what was being implied in the comment I was responding to.

But to answer your question, you never need to call autoload with flags other than "-Uz" 99.99% of the time. So the idea that you have to consult the manual each time to figure out the flags is plainly not true. As for the fact that you have to call autoload to bring autoloaded functions into scope, what else did you expect? Fish's behavior of bringing undeclared functions into scope isn't exactly intuitive either.

That's what I'm talking about. I'm super comfortable reading the man pages for things, but if a tool wants to take over all the boilerplate and do things for me, awesome! Sure, I can add a function by editing rc files. That doesn't scare me one bit. But... why? There's a lot to be said for convention over configuration.

For context, for a while I was the FreeBSD port maintainer for shells/bash-completion. I'm (too) familiar with the plumbing of various shells. I can do all the manual work myself, but there are lots of things I'd rather be doing instead.

Or even more simplified:

    funced foo
    funcsave foo

funced will either allow you to edit it inline, with a clever multiline system, or through your $EDITOR.

funcsave will record the file to the place you want once you're happy with the changes.

Which means you can funced as many times as you want on both new and old alike until you're happy with the function.

Or even easier:

    funced foo

Then edit your function in the editor, save and close it, and then:

    funcsave foo

to make sure it's there in the future sessions. Without that second step you can create one-time helper functions for the active session.

I've been using fish for longer than I can remember, but I almost never write fish functions. The out of the box experience is already much better than bash/zsh (out of the box, not including plugins/etc).

I also prefer the basic syntax for things like for and while looks on the command line, the way they get formatted. With bash I always had to look up the syntax because I didn't use it much. Fish, I barely have to look up things because they are pretty intuitive, for the most part.

Also, no adding `export X=Y` to your .bashrc because you can just `set -U` and it automatically saves it between sessions.

> It has some serious limitations as a scripting language, namely lack of proper subshell support and background process control. The relevant issues have been open for years with no clear resolution in sight. (which is fair, these are very hard problems and it's an open-source project with finite resources)

You say that but I'd been writing a shell in my spare time and I solved those problems over the course of a few weeks. For me though, they were important problems to solve because few other lesser mainstream / alternative shells addressed those problems and thus they became all the more tantalising problems to solve. In Fish's case, they might be lower priority jobs.

Unfortunately though, I also broke job control support again earlier this year and haven't had the spare time during the pandemic (my kids have been understandably more demanding of my time now that I'm working from home) to fix it. So I can't demo that particular feature as working. As an aside, this is also a good lesson to everyone to write robust tests....

In particular I think Fish struggles with backgrounding of functions (backgrounding of non-fish commands seems to work fine).

  # these behave the same in bash but differently in fish
  some_command &  # this works
  some_function & # this does not

The relevant issues are listed here if you're curious about why it's difficult to implement this in Fish: https://github.com/pirate/fish-functions#issues-with-fish

Thanks for the link. Makes sense that if Fish doesn't fork itself and isn't multi-threaded then that would be a difficult feature to implement. I had the same consideration right at the conception of my project: fork or multi-thread? I went with the latter. But my shell diverges quite a bit from the typical design a shell would take so there's a lot of reasons it's sub-optimal compared to the excellent work the Fish guys have done with their shell.

This is off topic, but I'm curious about your top 5 most game-changing upgrades to your dev environment.

Just set up TabNine, what are the other 3?

Clipboard history manager (I use Alfred's on macOS), TabNine, Fish Shell, ripgrep/ag, and SublimeText's jump to definition & "show usages" for all symbols in the current project.

I will add fzf with the fish plug in, entr, z...

I personally use autojump but fzf is excellent as well.

I've a similar collection of "functions", but I implemented them just as plain bash/sh scripts in my ~/bin. I think putting your functions into regular executables on the path would have been more portable. That way you wouldn't need to call them from a fish shell to run them (you can still use fish scripting language if you like).

Agreed, I've been gradually migrating all the big ones to https://github.com/pirate/bash-utils for the past few years.

The lack of associative arrays is what does it for me.

what are the most used functions in fish? i'm quite new, i find `z` very useful to move in folders