Skip to content

The += compatibility rule conflates arr+=(x), a Bash 3.0 parse error, with the 3.1 string form #1349

Description

@Chemaclass
Q A
OS Linux (container)
Shell & version bash 3.00.22 and 3.2.57
bashunit version 0.50.1

Summary

test_src_has_no_append_assignment uses one pattern for two constructs that fail on different Bash versions. The array form is a parse error on Bash 3.0 and parses fine on 3.2, so it belongs in a stricter class than the string form.

Current behavior

tests/unit/project/bash_compatibility_test.sh:61-72 matches both x+=y and arr+=(x) with a single regex, and treats them as the same rule.

Measured on a real Bash 3.00.22 and on 3.2.57, with the construct placed inside if false; then ... fi and inside an uncalled function:

Construct 3.0 bash -n 3.0 in dead code 3.2 bash -n 3.2 in dead code
x+=y passes inert passes works live
arr+=(x) fails fails passes works live

So arr+=(x) kills the file on Bash 3.0 even where it is never reached, and a green macOS run says nothing about it. x+=y is inert in dead code on both.

Expected behavior

Split the rule in two, so the two constructs can carry different minimum versions. x+=y is a Bash 3.1 feature that is safe inside a branch 3.0 never takes. arr+=(x) can never be made safe on 3.0 by any guard, because the failure happens at parse time.

This matters beyond tidiness: the split is what lets the compat test tell "needs a version guard" from "can never appear at all". Found while checking which constructs could sit behind a version gate.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

bugSomething isn't working

Type

No type

Projects

  • Status
    Done

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions