Storing shell scripts

What is the good common practice to store shell scripts? (bash, sh, …)

For now, I have a few bash and sh scripts in my $HOME directory

and I invoke them with

$ bash $HOME/script1.bash arg1, arg2, ...

or

$ sh $HOME/script2.sh arg1, arg2, ...

May I store them in some standard location and invoke them as normal
apps like ls, pwd, …?
e.g.

$ script1 arg1, arg2, ...
$ script2 arg1, arg2, ...

What is common practice here for advanced linux users?

Answers:

Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.

Method 1

You could store your scripts where they belong in the filesystem, and create a bin directory in your home. Adding

if [ -d "$HOME/bin" ] ; then
    export PATH="$HOME/bin:$PATH"
fi

in your .bashrc makes any executable placed in ~/bin discoverable. Finally, you just need to add files in the dorectory. You can use symbolic links to whatever script you want to make discoverable in ~/bin, which allows you to virtually change the name of the script and leave it where you want it on you filesystem. As an example, for a file my_script.sh, first make sure the file is executable

chmod u+x my_script.sh

then create a symbolic link

ln -s my_script.sh ~/bin/my_script

in the dedicated folder. Note that the extension was removed for convenience. You can now run your script from anywhere using the command my_script. You don’t have to make the symbolic link every time you edit the original my_script.sh file.

Edit : to make any text file executable via a certain interpreter, you can use a shebang. For a bash script, this means adding

#!/bin/bash

as a first line for the file. Note that the technique is not restricted to bash scripts, but also applies to python for instance using

#!/usr/bin/env python

Note : I personnally use ~/.local/bin instead if ~/bin as a personal preference, but most people use a bin directory directly located in their home, not hidden. Many distributions integrate it directly, such as debian or ubuntu which automatically add such a directory in the PATH if it exists (in the default .profile file they ship). My choice is based on the fact that many softwares already use .local/share, that I consider it as a configuration tool rather than as a set of real files (only symbolic links), and that I don’t want this folder to mess with the completion.

Method 2

The common path for such scripts is $HOME/bin. If such path is not in the $PATH, you should add

PATH=$HOME/bin:$PATH

to your .profile, .bash_profile, or .bashrc file.

Method 3

There are several steps to managing your shell scripts as real programs.

1. Turn on executable mode for your script:

   chmod +x myscript.sh

2. Start your script with an interpreter string (signaled by #!, the “hash-bang”) that tells the system how to run your script (the default is a shell script, but don’t rely on it).

    #!/bin/bash

3. Collect your scripts (along with compiled programs, it makes no difference) in a directory, and put this directory in your execution PATH. The customary place for your own scripts is $HOME/bin, but it’s really up to you.

   Put this in your ~/.profile and future shells will find your scripts exactly the way they find ls or make. (Unless the latter are aliases, of course :-))

   export PATH="$HOME/bin:$PATH"

4. Unix, unlike Windows, will not ignore the extension of executable files. If your script is called myscript.sh, you’ve got to type myscript.sh to run it. So rename it to myscript— the first line of the source tells you what kind of a script it is anyway.

   mv myscript.sh myscript

myscript is now a completely ordinary command, that you can run like everything else. If it is named the same as an executable already in your PATH, it will take precedence since we put $HOME/bin first. (You can put it at the end if you prefer.)

Method 4

You can store your scripts in a dedicated directory and then add that directory to your PATH variable. PATH is the way your system knows where to look for executables.

Method 5

Yes, it is possible to set it up so that you can invoke your scripts by name regardless of your working directory.

Steps

1. Make sure that the files in the directory are executable with chmod
2. If it’s a script rather than a binary executable, make sure the script starts with an appropriate shebang.
3. Make sure the directory containing the file is in PATH.
   • But make sure it’s an appropriate directory first (see next section)
4. If you want the script to be accessible via a simple command name, either remove the file extension or create a symlink with the desired name in the directory.
   • This is completely optional
   • To create a symlink: ln -s origfile linkname

Where to place the scripts

Now, in what directory should you put the executables? Ultimately, this comes down to how visible you want your scripts to be on the system:

• If you are a system admin and want everyone on the system to be able to run the scripts, place them in /usr/local/bin.
  • This directory is already in PATH by default on many systems
• If you want them to only be accessible to you, place them in ~/bin.

This other post has some useful information on the topic of where executable scripts and binaries should be placed: How do I know where to put things in linux?.

All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0