> I have the impression that you just overlook all the rest of the things that can go wrong when using Bash, because you are simply used to it, you know it and you know how it will behave

I don't write much of bash or fish, I mean scripts written by others. Encounter cryptic error messages then realize script is just assuming shell is POSIX

> Starship is too slow

Starship plenty fast for me. You say it's completely different than OMF but from what I see they both exist to customize your prompt, no?

If the script doesn't have a shebang I'd be extremely suspicious of it. If it does include a shebang, it will run under the chosen interpreter and your login or default shell won't matter.

If it's something you're trying to `source` then it can go wrong, but `bass` takes care of that if it's a POSIX-compatible script being sourced. If it's some other sort of script being sourced (PowerShell, NuShell, etc) you can have issues, though `fish` will usually fail to parse it and exit with error.

> I don't write much of bash or fish, I mean scripts written by others. Encounter cryptic error messages then realize script is just assuming shell is POSIX

I run most of my scripts in Bash, but what I can, I convert to Fish. If the advantages of Fish are less important than POSIX compliance, I won't suggest anything, because I have no need to be POSIX compliant, so maybe I don't really have the same concerns. :)

> Starship plenty fast for me. You say it's completely different than OMF but from what I see they both exist to customize your prompt, no?

Forgive me, I mistakenly assumed you meant that Starship runs too slowly. It depends on how you define prompt. Strictly it will be whatever is shown in the terminal when it waits for user input. OMF is a multi-tool that, in addition to modifying the appearance, acts as something like a plugin manager. Starship gives you "just the look". I think a good analogy would be to compare systemd and runit in 1 category.

How do you run scripts in bash while using fish as your shell?

you execute them like any other script. the script is not interpreted by your interactive shell but it specifies which shell/interpreter will be used to run it. that interpreter is then started for this script. your interactive shell does not limit what kind of scripts you can run. there was never a requirement that bash scripts need to be started from a bash shell. otherwise you could not even run python or other scripts from your shell.

Ah. I meant cases where lazy third-party scripts just assume my current shell is POSIX and don't explicitly make themselves run in bash.

Run "bash thirdparty.sh" instead of "./thirdparty.sh" to force bash.

if there is a bash script that does not start with #!/bin/bash where the instructions say to run it in bash, then it can be run as bash scriptfile; or cat scriptfile | bash;. both these forms work from any commandline shell

Yes. But I need to inspect the script to know to do it (or hope that if it didn't fail then it truly didn't fail). I am not saying it's an insurmountable challenge, just that there is some friction when using fish.

not really, unless there is a clear indication that it is a fish script, i's just asume it is bash and run it with that.

it's only work if the commands need to be run within fish itself and not a subshell. there are tools for that but i agree that sometimes i can't be bothered and then i'll just work in bash to do that job.

For example if I follow some README I may not even know whether it's a script or binary, so I guess I would need to know at least that before I run something with bash (or get "cannot execute binary":)

scripts begin with a line like

    #!/usr/bin/env bash

which works regardless of the executing shell