[ronjouch]

The literally billions of POSIX-compliant scripts and tools already out there will run just fine under fish with a hashbang/shebang (a first line that defines what the file executed should be opened with, e.g. `/usr/bin/env sh`) :) . And it's not as if adding a hashbang was painful, not having one is super bad anyway as it leads to uncertainty of whether the script is bash / sh / etc, and can lead to tricky corner cases.

I was a wary zsh user too, until I moved my zsh aliases to scripts with a proper hashbang, then migration to fish was painless, and the benefits are real: I get all the features I expected from my long-tuned zsh, with none of the maintenance/performance pains.

Actually, even for one-time personal scripts I still default to writing (ba)sh, because 1. habit/competence, 2. shellcheck, 3. what you say: examples and resources are everywhere.

Tangentially, upcoming fish will support POSIX && and || (in addition to maybe-even-weirder `; and` / `; or`), and already does if you build from sources now.

[prg318]

So long as you don't need to "source" any of these POSIX-compliant scripts into your environment... A shebang'd script cannot affect the environment of the parent process

[ronjouch]

Indeed, thanks for the precision. Never ran into that, though; config.fish is the only thing touching my environment.

[prg318]

Lucky for you. I have really come to love zsh's sh and ksh emulation features for this very reason. I have worked in various work environments where setting up a build environment or a testing environment required sourcing ksh scripts that sourced even more ksh scripts. The majority of the engineers on these teams would "deal with" ksh for this reason but a few of the "geekier" engineers would set up zsh with ksh emulation in order to work in a more usable shell.

[_verandaguy]

A shebang is good practice, but the state of the industry is such that many scripts don't use them (unfortunately).

I'm still of the opinion that fish is little more than a novelty and won't see widespread adoption in the long run.

[rovr138]

`bash script.sh` works fine. The source issue mentioned above is more of an issue.