I’ve done something similiar to this over the years for organization purposes and not having to change much between shells except add a path. You can also add cases that check your shell and do something slightly different if needed.
I’ve done something similiar to this over the years for organization purposes and not having to change much between shells except add a path. You can also add cases that check your shell and do something slightly different if needed.
I use ZSH with plugins but back when I switched away from bash, I also looked at fish. I didn’t use it back then because people say it doesn’t follow the POSIX standard but is that really an issue? It probably only extends it instead of taking things away, right?
Unless you have a particular reason for sticking to POSIX, who cares? I’ll take the user experience improvement without worry.
The thing is that, if you are not sticking to POSIX, you might as well use more widely available alternative scripting languages like perl or python, which are often included in most workspaces by default, so I’d say it’s more useful to get experienced in those than to get experienced in fish.
All POSIX compatible shells have their quirks and differences because the common POSIX part is rather small, so you will need to learn them anyway when switching from one to another. Fish is not that different from them (to much less extent than something like nushell) and it benefits from having less ancient baggage.