playbooks

home / skills / jackspace / claudeskillz / bash-script-helper

bash-script-helper skill

/skills/bash-script-helper

This skill helps you write robust bash scripts by enforcing best practices, debugging tips, and safe parameter handling.

npx playbooks add skill jackspace/claudeskillz --skill bash-script-helper

Review the files below or copy the command above to add this skill to your agents.

Files (3)
SKILL.md
973 B
---
name: bash-script-helper
description: Expert helper for bash scripting, debugging, and best practices
---

# Bash-script-helper

## Instructions

When writing or debugging bash scripts:
- Always use #!/bin/bash shebang
- Set -e (exit on error), -u (error on undefined var)
- Use [[ ]] instead of [ ] for tests
- Quote variables: "$variable" not $variable
- Use $() instead of backticks
- Check command exit codes: $?
- Use trap for cleanup
- Provide meaningful error messages
- Validate input parameters
- Argument parsing with getopts
- Reading files line by line
- Function definitions and calls
- Arrays and associative arrays
- Use set -x for trace mode
- shellcheck for static analysis
- Use echo/printf for debugging output
- Avoid eval
- Sanitize user input
- Use mktemp for temporary files
- Set proper file permissions


## Examples

Add examples of how to use this skill here.

## Notes

- This skill was auto-generated
- Edit this file to customize behavior

Overview

This skill is an expert helper for writing, debugging, and hardening Bash scripts. It provides practical guidance, common patterns, and checks to avoid fragile or insecure shell code. The goal is reliable, maintainable scripts that follow shell best practices.

How this skill works

I inspect your script for common pitfalls and recommend fixes: shebang, strict modes, quoting, test syntax, and safe temporary file handling. I suggest concrete code changes, add argument parsing, improve error messages, and show how to add traps and tracing for easier debugging.

When to use it

  • Creating new automation scripts for CI/CD, deployment, or data processing
  • Hardening scripts that run with elevated privileges or handle user input
  • Debugging failing scripts or intermittent errors in production
  • Refactoring legacy shell scripts to be more maintainable and portable
  • Adding robust argument parsing, validation, and helpful usage messages

Best practices

  • Start scripts with #!/bin/bash and enable set -euo pipefail for strict behavior
  • Quote variables ("$var") and prefer [[ ]] for conditional tests
  • Use $(...) for command substitution and avoid eval unless absolutely needed
  • Use trap to cleanup resources, mktemp for temporary files, and set proper file permissions
  • Validate inputs, sanitize user-provided data, and provide clear error messages
  • Run shellcheck for static analysis and use set -x only when tracing is needed

Example use cases

  • Add a getopts-based argument parser with usage output and validation for a backup script
  • Convert brittle string tests into [[ ]] checks with proper quoting to fix intermittent failures
  • Introduce trap and mktemp to safely handle temporary files during a data processing pipeline
  • Improve logging and error handling by checking exit codes and returning meaningful messages
  • Refactor a deployment script to use arrays, functions, and set -euo pipefail for reliability

FAQ

Should I always use set -euo pipefail?

Yes for most scripts: it fails fast on errors and undefined variables. Be aware of commands where nonzero exit is expected and handle them explicitly.

When is eval acceptable?

Avoid eval whenever possible. Only use it with fully controlled strings and after carefully considering injection risks; prefer other constructs like arrays or indirect expansion.

How do I debug a script that sometimes behaves differently in cron?

Export a minimal environment, set -x and redirect trace output to a file, and ensure absolute paths and full PATH are set in the script.