I have a few very simple bash scripts that I cobbled together for things that I do regularly. One of them is to run duplicity to do my backup tasks. Nothing clever just a bunch of if .. then statements really. As this needs to be run as sudo would it be best practice to put my script in /usr/bin ( or other location in PATH ) , chown to root.root and chmod to 700 ?

  • I would say use git to version-control your scripts, put local copies of the git repos somewhere you like in ~, and then symlink the scripts into ~/bin. – edwinksl Sep 26 '16 at 23:20
  • You mean git as in github in the clouds? – WinEunuuchs2Unix Sep 26 '16 at 23:21
  • 2
    @WinEunuuchs2Unix If you want your scripts to be available to other users, you should put them in /usr/local/bin. Otherwise, I would say just put them in ~/bin. Your own scripts in both directories should be safe when you upgrade. – edwinksl Sep 26 '16 at 23:43
  • 2
    As above, place them in /usr/local/bin. Just make sure your script names are unique & not an existing linux command/binary name. Myself just add a number to end of any script I create as I haven't seen any pre-existing linux names end in a number. ( not to say some really obscure ones may... – doug Sep 26 '16 at 23:47
  • 1
    @edwinksl Almost a year later I have to say ~/bin is the best place for most scripts as you don't have to use sudo to edit them as you do when they are stored in /usr/local/bin. – WinEunuuchs2Unix Aug 20 '17 at 1:07

I save my own scripts in /opt/scripts.

If your script should executeable by every system user, you can create a symbolic link to /usr/bin.

If only root should execute the script, you can create a symbolic link to /usr/sbin.

Command to add a symbolic link in /usr/bin/:

ln -s /opt/scripts/<script> /usr/bin/

You can execute the script, because /usr/bin/ is in your PATH by default.

  • 1
    I would recommend that instead of using /usr/bin as the target for user/local shell script - that it be /usr/local/bin (or /opt/bin) as per Filesystem Hierarchy Standard - Debian Wiki to avoid conflicts (most of the time, you want Ubuntu's provided scripts to take precedence). – shalomb Jan 22 '18 at 9:20
  • On most systems /usr/local/bin overrides /usr/bin, as it comes later in the path. This is on purpose, as the system does not put files there, so you can put files there, which SHOULD override the system provided ones. – allo Jan 22 '18 at 9:38
  • I marked this as the correct answer, even though both answers seem fine. Reason is, I eneded up taking a look at the FHS docs and came away with the understanding that /opt is there for exactly this purpose. I like the idea of them simply sym linking to my scripts in /usr/local/bin. Thanks for all the pointers. – hatterman Jan 22 '18 at 13:41

If no other users other than you uses these scripts:

Then you can keep them in /home/$USER/bin. Create the bin folder if it is not there and move the files there. The bin folder in your home will automatically get added to the PATH environment variable. The code is in the .profile:

# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/bin" ] ; then

See How to add /home/username/bin to $PATH?

Or in some systems it may be in .bashrc:

export PATH=${HOME}/bin/:${HOME}/.local/bin:${PATH}

Thanks Elder Geek

If these script are to be used by other users:

Then either /usr/local/bin or /opt/bin are good options. See Is there a standard place for placing custom Linux scripts?

Hope this helps


I have a directory that I use for the quick collection of my local tools or things that I deploy on various computers in /usr/local/apollo. There are branches off this directory for flags, bin and logs.

For the applications that I download and install outside of the default apt-get repositories are placed in /opt/ and a directory by the app's name, with one more sub-directory for the specific version of the application. This way my compiled version of an application like vlc or eclipse won't conflict with the distributed version.

My use of /opt is the way it's basically officially designed.

By the way the directories /usr/local/bin, /usr/local/apollo, and /opt survives a fresh OS version installation overwrite.

  • 1
    $ echo $PATH /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin I like the fact /usr/local/bin is already in the path one less thing to remember. I like your method of /opt/program/version I can use that for Kernel stuff I get and compile like EnhanceIO where they change things between kernel versions. Is /apollo a moon landing personal favorite or does it have Ubuntu meaning? – WinEunuuchs2Unix Sep 26 '16 at 23:48
  • What is the difference between /usr/local/bin and usr/local/sbin such that the latter gets nuked during upgrades? – WinEunuuchs2Unix Sep 26 '16 at 23:51
  • The installer Nukes the directories that it uses. It conveniently creates /usr/local directories, but it doesn't put anything in any of them. Those directories are populated by the user. Many source programs outside the repositories give the user the option of selecting where they want the install to go. The default in the config files are /usr/local/bin . So because of how common it is to use those directories, they are included in the user's path by default. By default the system checks for ~/bin and adds it to the path if it exists. – L. D. James Sep 26 '16 at 23:56
  • You mean the system checks for ~/bin during install or every boot? What is the difference between sbin and bin? They seem to coexist there must be quasi-rules on which you pick based on program type right? – WinEunuuchs2Unix Sep 26 '16 at 23:59
  • 1
    @WinEunuuchs2Unix On the ~/bin path... it's not added during installation. The system checks for it on every login and adds it to the $PATH if it exist during the login. Look at the last two lines of your ~/.profile settings. – L. D. James Sep 27 '16 at 0:07

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.