Where to Store Custom Scripts on Linux: A Best Practice Guide

Introduction

When you create custom scripts to support applications, automate tasks, or manage services on a Linux system, a common question arises: Where is the correct place to store them?

While you can technically place a script almost anywhere, following the Filesystem Hierarchy Standard (FHS) is a best practice that ensures your system remains organized, secure, and easy to maintain. This guide outlines the standard locations for your custom scripts and explains why they matter.

Recommended Locations

The best location depends on the script’s purpose and scope (i.e., whether it’s for all users, just one user, or a specific application).

1. /usr/local/bin

This is the standard and most recommended location for locally-installed executables and scripts that should be available to all users system-wide.

• Use Case: General-purpose utility scripts (e.g., custom data processing, application helpers) that any user on the system might need to run.
• Why: This directory is almost always included in the default $PATH for all users, meaning your scripts can be executed by name from any terminal.

2. /usr/local/sbin

This directory is similar to /usr/local/bin, but it is specifically intended for scripts and programs related to system administration.

• Use Case: Scripts that manage services, configure system settings, perform backups, or require root privileges to run.
• Why: Like /usr/local/bin, this directory is typically in the $PATH for the root user (and sometimes other admin accounts), separating administrative tools from general-user tools.

3. /opt/<application-name>/bin

If your scripts are tightly coupled to a specific, self-contained application (especially a third-party one), you might bundle them within that application’s directory.

• Use Case: Scripts that are only used to start, stop, or configure a single application installed in /opt/my-app.
• Note: This directory is not usually in the system $PATH. If you want to execute these scripts by name, you should create a symbolic link from /usr/local/bin to the script.

# Example: Link an app's script to the system-wide PATH
sudo ln -s /opt/my-app/bin/my-script /usr/local/bin/my-script

4. ~/.local/bin

If a script is only intended for a single user account and does not need to be available system-wide, place it in this directory within the user’s home folder.

• Use Case: Personal utility scripts, development helpers, and aliases that are specific to your user workflow.
• Why: This keeps your home directory clean and separates your personal scripts from system-wide scripts. On most modern Linux distributions, this directory is automatically added to the user’s personal $PATH when they log in.

Why /usr/local/* is the Standard

Using the /usr/local/ prefix is a core convention of the Filesystem Hierarchy Standard (FHS). This approach provides several key advantages:

• Package Manager Safe: Files in /usr/local/ are reserved for the local system administrator. This ensures your scripts will never conflict with or be overwritten by system packages installed by package managers like apt, yum, or dnf (which manage files in /usr/bin and /usr/sbin).
• **Already in $PATH:** As mentioned, /usr/local/bin and /usr/local/sbin are part of the default $PATH\ on most systems, making scripts immediately executable by name without any extra configuration.
• Clear Separation: It creates a clean distinction between the operating system’s core binaries (in /bin and /usr/bin) and the local, custom-installed binaries (in /usr/local/bin).
• Persistent Across Updates: System upgrades will not modify the contents of /usr/local/, protecting your custom scripts from being deleted or altered.

Final Steps: Setting Permissions

After you place your script in a system-wide location like /usr/local/bin, you must make it executable and set the correct ownership.

1. Make the script executable: Use the chmod command to add the execute (+x) permission.

   sudo chmod +x /usr/local/bin/my-custom-script
   

2. Set correct ownership: For system-wide scripts, ownership should typically be set to root:root.

   sudo chown root:root /usr/local/bin/my-custom-script
   

3. (Optional) Set explicit permissions: A common and secure permission setting for executable scripts is 755. This grants read, write, and execute permissions to the owner (root), and read/execute permissions to the group and all other users.

   # This command sets permissions to rwxr-xr-x
   sudo chmod 755 /usr/local/bin/my-custom-script
   

Conclusion

Choosing the right location for your custom scripts is key to maintaining a well-organized, secure, and standards-compliant Linux system.

• For general, system-wide scripts, use /usr/local/bin.
• For system administration scripts requiring root, use /usr/local/sbin.
• For user-specific scripts, use ~/.local/bin.