Don't think of it as magic, but as convention. Where do you put your function definitions? In the folder named "functions". There are only a handful of such things to learn.

> Where do you put your function definitions?

Inside ‘function’ blocks, like the language syntax defines for any other type of function. I can then throw those functions into any file I chose.

Having special functions inside special files just creates annoying special cases I need to look up.

In fish, you put the functions inside function blocks. There's nothing at all magical about that. However, if you write "function foo" inside a file named "foo.fish", then type the command "foo" at the shell prompt, then fish will look for a file named "foo.fish" and then execute the function "foo" defined inside it. That's its autoload mechanism.

That's the only remotely magical thing added here: by convention, an autoload function named "foo" is defined in ~/.config/fish/functions/foo.fish.

Your .bashrc, .zshrc, .profile, etc. files are also special. All that's going on is that there is folder where you can leave functions to be included in the main namespace, I don't see the big difference.

The difference as I understand it is your Fish equivalent of a $PS1 (and other Fish shell behaviours) have to be defined via that path. If I understand it correctly, it sounds a lot like git hooks but at a global scale rather than per repo.

Now I’ve got nothing against git hooks nor Fish per se, I just don’t see this particular model for defining behaviour to be convenient (eg what if you want to quickly change the prompt of a session without affecting other sessions?)

There might be more detail I’m missing and if that’s the case I apologise. But from what I’ve read thus far I’m not sold. It might appeal to others and good for them.

How would you normally do it? Because you can still put redefinitions of all the standard functions into a single file and load them with `.` as you would with other shells.

There's also this package, which the author admits only allows "slight" customization, to implement sessions: https://github.com/farzadghanei/fishion

Well I’m not suggesting the following is a better alt shell, but in murex you have something that’s a little bit akin to a Windows Registry in that all of the shell settings are navigable through a builtin called ‘config’

https://murex.rocks/docs/commands/config.html

You can set prompt functions with that; strings, ints and Booleans too. And ‘config’ comes with descriptions for each configurable thing, choices of options in many cases, and an easy way to default back to shell defaults too. So it’s dead easy to play around configuring whatever you want (you never need to leave the shell to look up an option).

The shell has its own problems though but it’s an interesting alternative take for grouping shell config.

>The difference as I understand it is your Fish equivalent of a $PS1 (and other Fish shell behaviours) have to be defined via that path.

They don't. You have to define the function somehow, but fish doesn't care about how that happens. It's just that if it's not defined yet it'll try to load it from the file.

If you want, you can just do it all in config.fish, like you'd do it all in .bashrc for bash.

>what if you want to quickly change the prompt of a session without affecting other sessions?

Then you can redefine the function, just like you could switch the value of $PS1.

Ok. That sounds a lot more sane then. Thank you for the clarification.

You can literally still do it the way you want, there's just a convention that `fish` uses to autoload so you don't have to if you don't want to.

It's as simple and seductive as Ruby on Rails was 20 years ago.

Bash and zsh have basically the same thing.

It's meant to give you a nice error message like

"foo is missing. You can install it with 'apt install foo123'"

See:

- https://zsh.sourceforge.io/Doc/Release/Command-Execution.htm... for zsh

- https://www.gnu.org/software/bash/manual/bash.html#Command-S... for bash

You could make it run arbitrary things, but then you're quite clearly misusing it and e.g. there's no way to make it return a different status, fish will still view the command as failed.

Setting a specific path as an “autoload” path to load shell functions is in bash and zsh too?

Okay so I think I understand your objection a bit more. So fish only wants you to define a function called fish_prompt in order to customize the prompt. That function can be defined however you want. It can be in fish’s equivalent of .bashrc (~/.config/fish/config.fish). Putting it in ~/.config/fish/functions/fish_prompt.fish is just leveraging more tooling around shell function autoloading and sane defaults.

You can achieve PS1-like functionality “simply” by placing this bit of code somewhere in your startup:

  function fish_prompt
      set -l prompt_symbol '$'
      fish_is_root_user; and set prompt_symbol '#'

      echo -s $hostname (set_color blue) (prompt_pwd) \
      (set_color yellow) $prompt_symbol (set_color normal)
  end

It’s very verbose but it runs as fast as both bash’s PS1 and zsh’s PROMPT and is much easier for someone new to fussing with prompts to comprehend.

Even as someone who doesn’t use fish day to day, I think fish’s prompt customization is much more approachable. If I had a powerline prompt I wanted to tweak, I’d know to start with `functions fish_prompt` to print out the current contents of the function and have the complete code to how the prompt is built. zsh requires a lot more reading and understanding of the prompt system before you can dig into how exactly it all works. IIRC, most dynamic bash prompts have similar issues. PS1 is just interpolated globals and color codes, creating a disconnect between the prompt variable and the shell functions that update it.