21

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?).

Community
  • 1
Mateusz Piotrowski
  • 4,623
  • 5
  • 36
  • 70
  • 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 01 '16 at 13:06
  • 1
    Depends what it's for, you can have env , rc , conf etc – 123 Aug 01 '16 at 13:08
  • @the_velour_fog Yeah, I've read about it. I am curious if there is a naming convention apart from the `#!/bin/sh` thing and removal of the unnecessary executable bit from permissions. – Mateusz Piotrowski Aug 01 '16 at 13:08
  • @the_velour_fog Typically you want the extension to give an idea of what the file contains. – 123 Aug 01 '16 at 13:09
  • 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 01 '16 at 13:16
  • @the_velour_fog You don't source any of those executable you mentioned... I don't know what point you are trying to make. – 123 Aug 01 '16 at 13:18
  • 6
    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 01 '16 at 13:19
  • @MateuszPiotrowski You can update your editor to accept whatever extension you want for highlighting. – 123 Aug 01 '16 at 13:19
  • I updated the question to explain why I feel it is unfair to put this question on-hold. – Mateusz Piotrowski Aug 01 '16 at 18:06
  • 1
    The word ["convention"](http://www.merriam-webster.com/dictionary/convention) (meaning #2) is what is probably leading towards "opinion-based" answers. The [open group spec for source](http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#dot) does not enforce any naming standard. – Jeff Schaller Aug 01 '16 at 18:55
  • 1
    I'm not aware of any convention, but my personal habit is to name such files with a .inc extension, indicating they are to be INCluded (sourced) in other scripts, and not to be executed directly. I think using a .sh or .bash extension is actually UNhelpful due to all of the people who think it should be used for commands executed at the shell prompt. – Monty Harder Aug 01 '16 at 19:25

2 Answers2

21

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.

Stéphane Chazelas
  • 522,931
  • 91
  • 1,010
  • 1,501
  • 1
    You can also exit if the script is not sourced (https://stackoverflow.com/q/2683279/4694621) – Mateusz Piotrowski Dec 12 '17 at 16:13
  • I prefer `/bin/false` to `/bin/echo` as the former ensures a 'fail' exit code if the file is accidentally executed (but you do lose the text feedback you get with echo) – Ben Page Dec 03 '21 at 14:11
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
Stéphane Chazelas
  • 522,931
  • 91
  • 1,010
  • 1,501
Luciano Andress Martini
  • 6,490
  • 4
  • 26
  • 56
  • 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 01 '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 01 '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 01 '16 at 15:29