Obviously there are some differences between executable files in bin
directories, and editable "source" files.
- For source files, it is helpful to have a suffix so you can see what is what, and to help some less-intelligent tools that fail to scan the
#!
line.
- For modules, they're only used by a related set of programs, all of which use the same interpreter (or no interpreter), and it is conventional to include
.pm
, .sh
or .so
in such cases.
- For executable programs, its name is part of the "programming contract" by which users and other scripts invoke it. It is important that the name does not change even if the implementation does; so obviously the filename should not have a suffix
In the case of a compiled program, the difference between "source" and "executable" is obvious: one contains source code, the other contains machine language or interpreted bytecode. In the case of a script, there's no obvious difference, but the make
command maintains a notional separation between the "source code for a script" and the "executable version of a script": its default "compiler" for "shell script" is simply cp
.
I would recommend keeping a separate $HOME/source
directory, and either:
- keeping a symlink, such as made by
ln -s ../source/foo.sh $HOME/bin/foo
; or
- manually copy them after making changes (and testing them), using
install -m 755 foo.sh ../bin/foo
; or
- using a
Makefile
rule to perform a syntax check before copying the source file from $HOME/source
into $HOME/bin
Footnote: a shell script module is only usable by another shell script, and modifies the internal context of that script using the .
or source
built-in commands. This is different from an executable script, which (like any program) runs as a separate process and cannot modify its parent process. As a rough convention, modules go in /usr/lib/name_of_program/name_of_module.sh
whereas commands go in /usr/bin/name_of_command
(without any suffix).