10

I was wondering if there is a convention for file type extensions for shell scripts you want to source instead of run. For example:

  1. If I want to run this script in a subshell.

    ./script.sh 
    
  2. If I want to remember to run this script from the current shell.

    . script.source 
    

Is there a convention (like POSIX for example) for a filetype in the second example? Something like .source or .sourceme?


Update

This question does not ask about any opinion. I clearly stated that I would like to know if there is a standardized file extension for this kind of scripts. This question is even less opinion-based than this well received question on a similar issue (Use .sh or .bash extension for bash scripts?).

  • 1
    Some people think that shell scripts that can be run a executables (i.e. they begin with #!/bin/sh or similar should have no extension, because the user should not need to care about what language the underlying script was written in. – the_velour_fog Aug 1 '16 at 13:06
  • 1
    Depends what it's for, you can have env , rc , conf etc – 123 Aug 1 '16 at 13:08
  • 1
    @123 it depends, sometimes once you build something thats useful and put it into $PATH , you come to use all the time , so its like, ps, ls, curl and all the other commands, then you start to build shell completion functions around it, I find its ok to drop the extension. But yes, when you are sourcing a shell script, that are not executable by themselves, I would not chmod +x them, and I would name them script.sh. also I often assign an extension purely because if I don't I won't get syntax highlighting on my editor. – the_velour_fog Aug 1 '16 at 13:16
  • 5
    There is no convention. If you are in a company or if you are collaborating in a share project (eg opensource) then you might have local standards to conform with, but there is no de facto convention. – Stephen Harris Aug 1 '16 at 13:19
  • 1
    The word "convention" (meaning #2) is what is probably leading towards "opinion-based" answers. The open group spec for source does not enforce any naming standard. – Jeff Schaller Aug 1 '16 at 18:55
17

I'd use .sh (for files in the POSIX sh language, .bash for non-sh-compatible bash files, that is the extension identifies the language the script is written in) for files intended to be sourced (or more generally not intended to be executed), and no extension for files that are meant to be executed.

You can also add a:

#! /bin/echo Please-source

she-bang, so that when executed by mistake (though I'd expect those files should not be given execution permissions, which would already prevent execution), you get a notice that it should be sourced instead.

4

In case of source files, i think the best way is .conf for files that configure your script and .shlib or .shlibs for files that have functions or other utils.

If you want to prevent your script to run with the wrong shell, and hashbang is not enough for you, you can use this:

if [ "$(readlink "/proc/$$/exe")" != "/bin/bash" ]; then
      echo >&2 "CAUTION: Wrong interpreter detected. You must use bash."
      exit 1
fi
  • 1
    If you're going to use the Linux-specific /proc/$$/exe, you might as well do it as case $(readlink "/proc/$$/exe") in */bash)..., though here, I'd simply use: if [ -z "$BASH_VERSION" ]. (echo should be echo >&2). (I like you .conf or .shlibs (but for sh files) extensions though it may not help syntax highlighters that rely on the extension). – Stéphane Chazelas Aug 1 '16 at 13:50
  • Yes i see this .shlibs, in some kind of program that i donwload, but i dont remember, so i started using this. Thank you very much for the tip, i will edit the question with the readlink version much more beautiful. ;-) – Luciano Andress Martini Aug 1 '16 at 13:59
  • @StéphaneChazelas Syntax highlighting may be triggered through meta-data in the files themselves (atleast for Emacs and Vim), so the choice of filename extension is irrelevant in that respect. – Kusalananda Aug 1 '16 at 15:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.