I just drop it. Very little reason to use it when my ~/bin is nothing but shell script. If I made the script with the intention to share, .bash for bash specific script, .sh for POSIX compliant script.

If we’re talking specifically about executable scripts, here is the link from #bash’s (libera.chat) factoid on the matter:

Don’t use extensions for your scripts. Scripts define new commands that you can run, and commands are generally not given extensions. Do you run ls.elf? Also: bash scripts are not sh scripts (so don’t use .sh) and the extension will only cause dependencies headaches if the script gets rewritten in another language. See talisman.org/…/commandname-extensions-considered-…

It’s for these reasons that I keep my executable scripts named without extensions (e.g. install).

I sometimes have non-executable scripts: they’re chmod -x, they don’t have a shebang, and they’re explicitly made for source-ing (e.g. library functions). For these, I give them an extension depending on what shell I wrote them for (and thus, what shell you need to use to source them), e.g. library.bash or library.zsh.

On my personal computer ~/bin has two directories.

One is for my .sh files and the other is a system link to them. The system link drops off the .sh and all scripts are added to my PATH

in most cases no extension

no extension for commands that are like tools - placed in /usr/local/bin/ or user’s folder ~/.local/bin/

but I add extension for scripts that matters where they are placed, for example ./build.sh and /mnt/my-disk/snapshot.sh

and source scripts in repo folder, such as github repo tools/src/tool-name.sh

I symlink it from bin with no extension, example: ln -sr ~/dev/gh/my-script-repo-name/my-script.sh ~/.local/bin/my-script original source has extension, but not in bin folder