Showing 29 of 29 scripts
Shell Script Library(1)
Name
Production-ready Bash scripts for system administration, backups, monitoring, security, and DevOps. Browse by category, copy to clipboard, or download as .sh files.
sponsored
Guide
What Are Shell Scripts?
Shell scripts are plain-text files containing a sequence of Bash commands that automate repetitive tasks. Instead of typing commands one by one, you write them into a .sh file and execute the entire workflow at once.
How to Use This Library
Browse scripts by category — backups, monitoring, security, Docker, and more. Each script includes usage instructions and customizable variables. Copy to your clipboard or download the .sh file directly.
Why Use Pre-Built Scripts?
Writing reliable shell scripts from scratch takes time, especially for tasks like log rotation, automated backups, or health checks. This library gives you battle-tested starting points so you can focus on customization rather than boilerplate.
Make scripts fail safely with set -euo pipefail
Most script bugs come from carrying on after something already went wrong. Put set -euo pipefail near the top: -e exits on the first failing command, -u turns a typo in a variable name into an error instead of an empty string, and -o pipefail makes a pipeline fail when any stage fails, not just the last one. Also quote every variable expansion ("$file", not $file) so filenames with spaces don't split into separate arguments.
How to run a script
Start the file with a shebang such as #!/usr/bin/env bash so it runs with bash rather than whatever sh happens to be. Make it executable with chmod +x backup.sh and run it as ./backup.sh, or run bash backup.sh, which doesn't need the executable bit. bash -n backup.sh checks the syntax without running anything, and bash -x backup.sh prints each command as it executes — the quickest way to see where a script goes wrong.
Check scripts with ShellCheck
ShellCheck is a linter for shell scripts that catches unquoted variables, misused test brackets, commands whose exit codes are ignored and many other classic mistakes, and explains each finding. Install it with apt install shellcheck, dnf install ShellCheck or brew install shellcheck, then run shellcheck backup.sh. Running it on every script you copy from the internet — including these — is a cheap safety net.
Run scripts on a schedule
Add a cron entry with crontab -e, for example 0 2 * * * /opt/scripts/backup.sh >> /var/log/backup.log 2>&1 to run at 02:00 every night and keep its output. Cron runs with a minimal environment and a short PATH, so use absolute paths for commands and files inside the script. For retries, dependencies or logging to the journal, a systemd timer is often the better fit.
Exit codes, logging and cleanup
Exit with 0 on success and a non-zero code on failure so cron, systemd and CI can tell the difference. logger -t backup "finished in ${SECONDS}s" writes a tagged line to syslog or the journal. Create temporary files with mktemp, and remove them with trap 'rm -f "$tmp"' EXIT so they are cleaned up even when the script exits early.
Customize variables without editing the logic
The scripts read settings from variables at the top. Give them overridable defaults with VAR="${VAR:-default}", so BACKUP_DIR=/mnt/backup ./backup.sh changes the target without touching the file. Keep passwords and API tokens out of the script itself — load them from an environment file with restricted permissions or from your secrets manager.