i’m pretty new to the shell scripting world and not sure, if i should give my scripts a .sh or .bash extension.

not sure what the pros and cons are.

  • GuybrushThreepwo0d
    link
    fedilink
    English
    arrow-up
    8
    ·
    1 year ago

    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

  • Kevin
    link
    fedilink
    English
    arrow-up
    7
    ·
    1 year ago

    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

    • HerbErtlinger@vlemmy.net
      link
      fedilink
      English
      arrow-up
      3
      ·
      1 year ago

      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.

  • igemnace@lemmy.sdf.org
    link
    fedilink
    English
    arrow-up
    7
    ·
    edit-2
    1 year ago

    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.

    • GammaM
      link
      fedilink
      English
      arrow-up
      1
      ·
      1 year ago

      I do the same, but I include shebangs anyway out of habit.

  • vvv
    link
    fedilink
    English
    arrow-up
    5
    ·
    1 year ago

    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

  • sin_free_for_00_days@lemmy.one
    link
    fedilink
    English
    arrow-up
    3
    ·
    1 year ago

    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.

  • mwqer
    link
    fedilink
    English
    arrow-up
    3
    ·
    1 year ago

    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.

  • GuybrushThreepwo0d
    link
    fedilink
    English
    arrow-up
    2
    arrow-down
    1
    ·
    1 year ago

    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