Just put the shebang at the top of your script:
#! /usr/bin/env bash
I'm not a big fan of extensions because if you put the script in your $PATH
it's weird to type do_the_thing.bash
Keep posts about shell scripting! Here are some guidelines to help:
In general, if your submission text is primarily shell code, then it is welcome here!
Just put the shebang at the top of your script:
#! /usr/bin/env bash
I'm not a big fan of extensions because if you put the script in your $PATH
it's weird to type do_the_thing.bash
Usually I have most of my (admittedly very few) scripts be .sh with #!/bin/bash. I do have a few that don't have an extension however, and those are in my $PATH intended to be used as shell commands
This is how I do it as well. Shell scripts that I include in a project are named with a .sh extension so other users can identify them easily. Scripts that I want to run as commands often are in my $HOME/bin/ and don’t have an extension. Sometimes those are convenience symlinks with easier names, so ~/bin/example might be a link to ~/repos/example-project/example-script-with-long-name.sh.
If we're talking specifically about executable scripts, here is #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 http://www.talisman.org/~erlkonig/documents/commandname-extensions-considered-harmful
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
.
I do the same, but I include shebangs anyway out of habit.
I stopped using extensions on anything meant to be an "executable" since it leaves me with the option to switch it's implementation. e.g. shell to python or some binary
I usually add the .sh
to the scripts in my ~/bin
folder. Just so when I go to edit them I know if they are a script or a binary or whatever.
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.
Just put the shebang at the top of your script:
#! /usr/bin/env bash
I'm not a big fan of extensions because if you put the script in your $PATH
it's weird to type do_the_thing.bash