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@programming.dev
    cake
    link
    fedilink
    English
    81 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
    71 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
      31 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
    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
      11 year ago

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

  • @vvv@programming.dev
    link
    fedilink
    English
    51 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
    link
    English
    31 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
    31 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@programming.dev
    cake
    link
    fedilink
    English
    21 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

  • @onescomplement@lemm.ee
    link
    fedilink
    English
    1
    edit-2
    1 year ago

    On my personal computer, ~/bin has two directories within it.

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