Cursor Rules for Bash: Safer Shell Instructions to Reuse

Cursor rules for Bash tell the assistant to quote variables, check paths before operating on them, use safe patterns for common tasks, and stop for review before running destructive commands. Shell scripts have a long tail of easy mistakes, and a rule file that names the most important ones is more reliable than hoping the assistant remembers.

fenbs keeps the agreed project rules and documented exceptions: why a specific script uses a pattern that looks wrong, which commands require a person to approve before running, and where the last session left a scripting task. Rules and decisions together give the assistant the project context that a generic Bash guide cannot supply.

What Bash rules should cover

Bash has no type system and few guardrails. The common failure modes are predictable: unquoted variables that break on filenames with spaces, missing checks before rm or mv, commands that fail silently, and scripts that run as root when they should not. A rule that names these patterns gives the assistant a short list to check before finishing any script.

• Quoting: always double-quote variable expansions unless word-splitting is intentional.
• Error handling: use set -e or explicit checks after commands that can fail silently.
• Path validation: check that a path exists and is the right type before operating on it.
• Destructive commands: require a human review confirmation before rm -rf, truncate, or overwrite operations.
• Script header: shebang, set -euo pipefail, and a comment describing what the script does.

Instructions versus enforcement

A Cursor rule is an instruction, not a guard. It tells the assistant what to do; it does not prevent the assistant from doing something else. A rule that says "never run rm -rf without a review" relies on the assistant following the instruction. It does not add a technical barrier.

This is an important framing for what Cursor rules can and cannot achieve. Rules make the assistant aware of what it should not do. They do not prevent it from doing something it judges necessary. A rule that says "never run rm -rf without confirmation" will stop most assistant-generated destructive commands, but the guarantee comes from the assistant following its instructions, not from a technical barrier. That is a meaningful improvement over no rule at all, but it is not a substitute for a proper guard.

That distinction matters for Bash more than for most languages, because a Bash mistake can destroy data or break a system. For commands that carry real risk, the rule should require the assistant to stop and ask rather than proceeding. For actual enforcement, use a separate mechanism: a pre-commit hook, a CI check, or a human review step outside the assistant.

---
description: Bash scripting conventions
globs: "**/*.sh,**/*.bash,.env.example"
alwaysApply: false
---

## Script structure
- Start every script: `#!/usr/bin/env bash` then `set -euo pipefail` then a comment describing purpose.
- Exit with a non-zero code and an error message when a required condition fails.

## Quoting and variables
- Always double-quote variable expansions: `"$var"`, `"$1"`, `"${array[@]}"`.
- Use `${var:-default}` for variables that may be unset.

## Path safety
- Check that a path exists before operating on it: `[[ -f "$file" ]] || exit 1`.
- Never operate on user-supplied paths without validation.

## Destructive commands
- Do not write a `rm -rf` command without stopping to confirm the path and ask for review.
- Do not truncate or overwrite a file without confirming the path is correct.

## Error handling
- Pipe operations that can fail: check the exit code with `$PIPESTATUS` or rewrite with explicit checks.
- Log errors to stderr with `echo "Error: ..." >&2`.

Quoting and word splitting

Unquoted variable expansions in Bash undergo word splitting: a filename with a space becomes two arguments. rm $file is safe when $file is report.txt and dangerous when it is my report.txt. Requiring double quotes around every variable expansion is the simplest defense against this class of bug.

Globbing is a related trap. Unquoted variables that contain glob characters — *, ?, [ — expand against the filesystem. A variable set to report*.txt may match files the script was not meant to touch. Double-quoting the variable stops the expansion, which is the desired behavior in almost every case.

The exception is when word splitting is intentional, such as passing a space-separated list of arguments stored in a variable. When that is the case, a comment explaining the deliberate choice makes the intent visible to reviewers and prevents the next assistant from quoting it incorrectly in a cleanup pass.

Scoping to shell files

A glob pattern like **/*.sh activates the rule for shell script files. If your project has shell scripts without the .sh extension, add those patterns. If some scripts are generated and should not be edited directly, note that in the rule so the assistant does not modify them.

For organizing multiple rule files in a project, see cursor rules hierarchy and cursor rules globs. For reusing a Bash rule set across multiple projects, see cursor rules library. For examples from other languages, see cursor rules examples.

How to set up Bash rules with fenbs

1. Create a free account and add your project.
2. Record any known exceptions to the standard Bash rules in fenbs: scripts that use word splitting intentionally, commands that run as root with explicit approval, or inherited scripts that should not be changed.
3. Place the .cursor/rules/bash.mdc file at the project root and adjust the globs to match your script naming.
4. Connect Cursor via Integrations and ask it to read the project context before working on any scripting task.
5. When a scripting decision comes up during a task, record it as a Decision in fenbs before ending the session.

For more on testing and debugging shell scripts, see bug bash. For using Cursor from the command line, see Cursor CLI. For general AI project rule patterns, see cursor rules for AI projects.