{"id":465,"date":"2026-09-05T12:20:18","date_gmt":"2026-09-05T12:20:18","guid":{"rendered":"https:\/\/www.vps.tc\/blog\/?p=465"},"modified":"2026-09-14T15:21:51","modified_gmt":"2026-09-14T15:21:51","slug":"what-is-bash-scripting-linux-automation","status":"publish","type":"post","link":"https:\/\/www.vps.tc\/blog\/en\/what-is-bash-scripting-linux-automation\/","title":{"rendered":"What Is Bash Scripting? A Guide to Linux Automation"},"content":{"rendered":"
Table of Contents<\/strong><\/p>\n
    \n
  1. What Bash Scripting Does for a Linux Server<\/a><\/li>\n
  2. The building blocks of a Bash script<\/a><\/li>\n
  3. Variables and command substitution<\/a><\/li>\n
  4. Conditions and exit codes<\/a><\/li>\n
  5. Functions, loops, and repeated work<\/a><\/li>\n
  6. A practical automation example: a disk usage alert<\/a><\/li>\n
  7. Scheduled Bash tasks with cron<\/a><\/li>\n
  8. Input validation and safer Bash habits<\/a><\/li>\n
  9. When Bash should give way to Python or Ansible<\/a><\/li>\n
  10. Testing and monitoring your script<\/a><\/li>\n
  11. Frequently asked questions<\/a><\/li>\n<\/ol>\n<\/div>\n

    What Bash Scripting Does for a Linux Server<\/h2>\n

    At 3 a.m., a repeated command stops being a small task. It becomes a maintenance problem. Checking a few files, measuring disk usage, archiving old logs, or restarting services in a particular order can look harmless once. Repeated often enough, these jobs waste time and leave room for mistakes.<\/p>\n

    What is Bash scripting?<\/strong> It is a way to combine commands, variables, and control structures in a file that Bash can execute. You can turn manual steps into a sequence, add conditions, produce useful output, and run the work on a schedule with tools such as cron.<\/p>\n

    I still use Bash for small systems administration jobs. Not every task needs a YAML file. My rule is simple: after doing something twice, I ask what would happen if another person had to run it tomorrow. If the answer is unclear, I write a script and make its behavior safer before repeating the task by hand.<\/p>\n

    The building blocks of a Bash script<\/h2>\n

    Bash scripts commonly use a .sh<\/code> extension. It is not required; Linux cares about the file contents and how you invoke it. The extension does tell the next person fairly quickly that the file contains a shell script.<\/p>\n

    At the top of the file, specify the interpreter:<\/p>\n

    #!\/usr\/bin\/env bash\n\nprintf 'Hello, %sn' \"$USER\"<\/code><\/pre>\n
    The first line is the shebang. \/usr\/bin\/env bash<\/code> looks for Bash in the system’s PATH<\/code>. Some distributions also provide Bash at \/bin\/bash<\/code>. Using env<\/code> can make the script a little easier to move between systems, provided Bash is installed and available in PATH<\/code>.<\/p>\n
    I use printf<\/code> because its formatting behavior is more predictable than echo<\/code>. For one short message, either is fine. Scripts tend to collect small ambiguities as they grow.<\/p>\n
    Creating and running your first script<\/h3>\n
    Open a new file:<\/p>\n
    vim disk-check.sh<\/code><\/pre>\n
    Add these lines:<\/p>\n
    #!\/usr\/bin\/env bash\n\nset -u\n\nprintf 'Hostname: %sn' \"$(hostname)\"\nprintf 'Date: %sn' \"$(date '+%Y-%m-%d %H:%M:%S')\"\nprintf 'Disk usage:n'\ndf -h \/<\/code><\/pre>\n
    set -u<\/code> makes the script fail when it tries to use an unset variable. It does not catch every possible error, but it helps me find spelling mistakes early.<\/p>\n
    Make the file executable and run it:<\/p>\n
    chmod +x disk-check.sh\n.\/disk-check.sh<\/code><\/pre>\n
    The -a<\/code> flag is not involved here; +x<\/code> adds execute permission. You can also invoke the file directly with Bash:<\/p>\n
    bash disk-check.sh<\/code><\/pre>\n
    .\/disk-check.sh<\/code> requires execute permission and a usable shebang. bash disk-check.sh<\/code> explicitly runs the file with Bash. If you use Bash-specific arrays or [[ ... ]]<\/code>, do not invoke the script with sh<\/code>; on some systems, sh script.sh<\/code> starts a different shell.<\/p>\n
    Variables and command substitution<\/h2>\n
    Scripts become useful when fixed text is separated from values that change:<\/p>\n
    #!\/usr\/bin\/env bash\n\nBACKUP_DIR=\"\/var\/backups\"\nHOST=\"$(hostname -s)\"\nNOW=\"$(date '+%Y%m%d-%H%M%S')\"\n\nprintf 'Server: %sn' \"$HOST\"\nprintf 'Backup directory: %sn' \"$BACKUP_DIR\"\nprintf 'Time label: %sn' \"$NOW\"<\/code><\/pre>\n
    Do not put spaces around the equals sign when assigning a variable. Also, do not skip the double quotes when expanding one. If a path contains spaces, \"$BACKUP_DIR\"<\/code> and $BACKUP_DIR<\/code> do not behave the same way. I avoid spaces in server paths, but I keep the quoting habit anyway.<\/p>\n
    Use $(...)<\/code> to store command output. The older backtick syntax still works, but nested commands are harder to read with it. Readability matters when you are debugging from a console with cold coffee beside you.<\/p>\n
    Accepting arguments<\/h3>\n
    Editing a path inside the script every time you run it is not practical. Command-line arguments solve that:<\/p>\n
    #!\/usr\/bin\/env bash\n\nif [[ $# -ne 1 ]]; then\n    printf 'Usage: %s DIRECTORYn' \"$0\" >&2\n    exit 1\nfi\n\nTARGET=\"$1\"\n\nif [[ ! -d \"$TARGET\" ]]; then\n    printf 'Error: directory not found: %sn' \"$TARGET\" >&2\n    exit 2\nfi\n\ndu -sh -- \"$TARGET\"<\/code><\/pre>\n
    $#<\/code> is the number of arguments, $1<\/code> is the first argument, and $0<\/code> is the script name. The --<\/code> tells the command that options have ended, so a path beginning with a hyphen is less likely to be interpreted as an option. A small detail. In file operations, small details can become night-shift-sized details.<\/p>\n
    Conditions and exit codes<\/h2>\n
    Reliable automation needs more than a list of commands. When one step fails, you need to decide whether the next step should run.<\/p>\n
    #!\/usr\/bin\/env bash\n\nSERVICE=\"nginx\"\n\nif systemctl is-active --quiet \"$SERVICE\"; then\n    printf '%s is running.n' \"$SERVICE\"\nelse\n    printf '%s is not running.n' \"$SERVICE\" >&2\n    exit 1\nfi<\/code><\/pre>\n
    systemctl is-active --quiet<\/code> returns an exit code without unnecessary output. In the shell, 0<\/code> means success and a non-zero value means failure. That feels backwards at first. It is not.<\/p>\n
    Here are common file-test operators:<\/p>\n\n\n\n\n\n\n\n\n\n
    Test<\/th>\nMeaning<\/th>\n<\/tr>\n<\/thead>\n
    -f<\/code><\/td>\nDoes a regular file exist?<\/td>\n<\/tr>\n
    -d<\/code><\/td>\nDoes a directory exist?<\/td>\n<\/tr>\n
    -r<\/code><\/td>\nIs it readable?<\/td>\n<\/tr>\n
    -w<\/code><\/td>\nIs it writable?<\/td>\n<\/tr>\n
    -s<\/code><\/td>\nDoes the file exist and have a size greater than zero?<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
    For scripts where several commands must succeed, you will often see this near the beginning:<\/p>\n
    set -Eeuo pipefail<\/code><\/pre>\n
    -e<\/code> exits on a failed command, -u<\/code> treats unset variables as errors, and pipefail<\/code> exposes a failure anywhere in a pipeline. -E<\/code> makes an ERR<\/code> trap behave more consistently inside functions and subshells.<\/p>\n
    Do not add these options blindly. For example, grep<\/code> returns a non-zero status when it finds no matches. That may be expected information rather than a script failure. Know the intended result of each command first.<\/p>\n
    Functions, loops, and repeated work<\/h2>\n
    As a script gets longer, I use functions instead of copying the same code into several places:<\/p>\n
    log() {\n    printf '[%s] %sn' \"$(date '+%Y-%m-%d %H:%M:%S')\" \"$*\"\n}\n\nfail() {\n    log \"ERROR: $*\" >&2\n    exit 1\n}\n\nlog 'Starting checks'\n[[ -d \/var\/log ]] || fail '\/var\/log was not found'\nlog 'Checks completed'<\/code><\/pre>\n
    The log<\/code> function adds a timestamp to every message. That is useful when investigating when a cron job actually ran. You can follow the output through journalctl<\/code> or a log file.<\/p>\n
    Loops handle the same operation on several files:<\/p>\n
    for file in \/var\/log\/*.log; do\n    [[ -e \"$file\" ]] || continue\n    printf '%s: ' \"$file\"\n    wc -l < \"$file\"\ndone<\/code><\/pre>\n
    The [[ -e \"$file\" ]]<\/code> check prevents an unmatched glob from remaining as literal text when there are no matching files. I once left that check out of an older script. It tried to process a file literally named \/var\/log\/*.log<\/code>. No outage, just an unnecessary alert. Monitoring noise is its own kind of failure.<\/p>\n
    A practical automation example: a disk usage alert<\/h2>\n
    An alert that only says “the disk is full” is not very helpful. I want the affected filesystem and a quick view of the largest directories:<\/p>\n
    #!\/usr\/bin\/env bash\n\nset -Eeuo pipefail\n\nTHRESHOLD=80\nMOUNTPOINT=\"\/\"\n\nusage=$(df -P \"$MOUNTPOINT\" | awk 'NR==2 {gsub(\"%\", \"\", $5); print $5}')\n\nif (( usage >= THRESHOLD )); then\n    printf 'WARNING: %s is at %s%% usage.n' \"$MOUNTPOINT\" \"$usage\" >&2\n    printf 'Largest directories:n' >&2\n    du -xhd1 \"$MOUNTPOINT\" 2>\/dev\/null | sort -h | tail -n 8 >&2\n    exit 1\nfi\n\nprintf 'Disk is normal: %s%% used.n' \"$usage\"<\/code><\/pre>\n
    df -P<\/code> makes the output more consistent for scripts. awk<\/code> removes the percent sign and extracts the number. du -x<\/code> stays on the current filesystem instead of crossing into another mount, which helps prevent an unexpected remote filesystem from making the check slow.<\/p>\n
    One night at around 3 a.m., \/var<\/code> was close to full. My first instinct was to restart the service. I had to train that instinct out of myself. ncdu<\/code> showed that an application’s log rotation configuration had been disabled, so I fixed the logrotate rule instead. The Bash script was not the diagnosis; it turned the right check into something repeatable.<\/p>\n
    Scheduled Bash tasks with cron<\/h2>\n
    Manual execution is fine while testing. For regular checks or backups, cron can run the script on a schedule. Test it first as the same user cron will use:<\/p>\n
    sudo -u backup \/usr\/local\/sbin\/disk-check.sh<\/code><\/pre>\n
    Then open that user’s crontab:<\/p>\n
    crontab -e<\/code><\/pre>\n
    This runs the script every 15 minutes:<\/p>\n
    *\/15 * * * * \/usr\/local\/sbin\/disk-check.sh >> \/var\/log\/disk-check.log 2>&1<\/code><\/pre>\n
    The cron environment is smaller than your interactive shell. PATH<\/code> may differ, the working directory may not be what you expect, and environment variables may be missing. Use absolute paths for critical commands or define a suitable PATH<\/code>:<\/p>\n
    PATH='\/usr\/local\/sbin:\/usr\/local\/bin:\/usr\/sbin:\/usr\/bin:\/sbin:\/bin'\nexport PATH<\/code><\/pre>\n
    A scheduling change once taught me this the uncomfortable way. I was editing what I believed was a staging crontab when tab completion showed the hostname: production. Since then, I check the hostname before commands and use a red prompt for critical sessions. Thirty seconds is cheap.<\/p>\n
    Preventing overlapping runs<\/h3>\n
    For backups or long-running reports, use flock<\/code>:<\/p>\n
    #!\/usr\/bin\/env bash\nset -Eeuo pipefail\n\nexec 9>\/run\/lock\/my-backup.lock\nflock -n 9 || {\n    printf 'Another backup is already running.n' >&2\n    exit 1\n}\n\nprintf 'Backup started.n'\nRun the long backup command here<\/code><\/pre>\n
    The script obtains a lock through file descriptor 9. The lock is released when the script exits. That prevents two copies of the same cron job from writing to the destination at once.<\/p>\n
    Input validation and safer Bash habits<\/h2>\n
    If a Bash script runs with root privileges, adding user input directly to a command is risky. eval<\/code> is especially dangerous because it treats text as shell code.<\/p>\n
    For a script that accepts a path, at least do the following:<\/p>\n