Summary

When linting shell scripts, bashrs produces false positive warnings in several scenarios where the code is actually correct.

Issues

1. Heredoc with quoted delimiter still parsed for shell syntax

When using a heredoc with a quoted delimiter (<< 'EOF'), the content should be treated as literal text with no shell expansion. However, bashrs still flags backticks inside as deprecated command substitution.

Example:

cat > output.md << 'EOF'
## Code Example

| File | Description |
|------|-------------|
| `config.json` | Configuration file |
EOF

Warnings produced (all false positives):

• SC2006: Use $(...) instead of deprecated backticks
• SC2046: Quote this and use $(...) instead of backticks
• SC2092: Remove backticks to avoid executing output
• SC2099: Use $(...) instead of deprecated backtick command substitution

Expected behavior: No warnings, since << 'EOF' prevents all shell expansion and backticks are literal markdown formatting.

2. SC2035 false positive for find -name patterns

Example:

find "$DIR" -name '*.json' -type f

Warning: SC2035: Use ./* so names with dashes won't become options

Why it's a false positive: The pattern '*.json' is a quoted argument to find -name, not a shell glob. The pattern is passed to find's internal matching, not interpreted by the shell.

3. SC2140 false positive for valid quote nesting

Example:

echo '{"version":"1.0","format":"json"}' > "$TRACES_DIR/output.json"

Warning: SC2140: Word is split between quotes

Why it's a false positive: This is valid bash - a single-quoted JSON string followed by redirection to a double-quoted path. There's no word splitting issue.

4. SC2062 false positive for already-quoted grep patterns

Example:

if ! echo "$VERSION" | grep -qE '^[0-9]+\.[0-9]+\.[0-9]+$'; then

Warning: SC2062: Quote the grep pattern so the shell won't interpret it

Why it's a false positive: The pattern is already single-quoted, so the shell won't interpret any special characters.

Environment

• bashrs version: latest from crates.io
• Shell scripts using set -euo pipefail
• Discovered while linting scripts in the aprender project

Workaround

Added these rules to .bashrsignore:

SC2006
SC2046
SC2092
SC2099
SC2140
SC2035
SC2062

However, this is overly broad and may hide legitimate issues elsewhere. Ideally bashrs should recognize these specific patterns as valid.

Suggested Fix

1. Heredocs: When parsing heredoc content with a quoted delimiter (<< 'EOF'), skip shell syntax analysis entirely
2. find -name: Recognize that patterns inside find ... -name 'pattern' are find glob patterns, not shell globs
3. Quote nesting: Better analysis of quote boundaries to recognize valid 'literal' > "$var" patterns
4. grep patterns: Check if the pattern argument is already quoted before warning about quoting