fix(awk): bound field operand recursion

[chaliy]

What changed

AWK field operands now charge unary -, +, and ! recursion against the same 100-level parser-depth budget as other recursive expressions. Over-limit programs fail with a bounded syntax diagnostic, while valid finite field expressions keep GNU Awk-compatible behavior.

The regression suite runs hostile inline and VFS awk -f programs in a supervised child process with CPU, stack, wall-time, and output limits, plus an address-space limit on Linux. It also verifies boundary behavior, malformed input recovery, session reuse, and finite-expression parity with GNU Awk when available.

Why

Unary chains beneath AWK's $ field operator bypassed the parser depth guard. Untrusted programs could recurse on the native stack instead of being rejected by the configured parser limit.

Before / After

Before: a 200-operator field operand such as $!!!!!!!!!!!!!!!!...1 parsed successfully instead of reaching the depth limit; the new bounded regression failed with exit code 0.

After: inline and awk -f variants using !, -, +, and mixed unary chains fail with exit code 2 and awk: fatal: expression nesting too deep (101 levels, max 100). The same session remains usable, and finite field operands match GNU Awk output and status.

Validation: just pre-pr; cargo bench -p bashkit --bench parallel_execution -- --noplot; bounded external production probe covering eight inline/file cases.

Risk

• Low
• AWK programs with more than 100 recursive field-operand levels are now rejected consistently with the documented parser limit.

Checklist

• Tests added or updated
• Backward compatibility considered

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	bashkit	bac76a8	Commit Preview URL Branch Preview URL	Oct 11 2026, 11:34 PM