bug: test builtin parse_int doesn't trim whitespace, breaks integer comparisons

[chaliy]

Description

The test / [ builtin's parse_int function doesn't trim leading whitespace before parsing integers. This causes integer comparisons to fail when the input comes from commands like wc that pad output with spaces.

Reproduction

count=$(find /app/data -type f | wc -l)
# count = "       3" (padded with spaces)
[ "$count" -ge 2 ] && echo "has files"
# Expected: "has files"
# Actual: comparison fails silently (parse returns 0, 0 >= 2 is false)

Real bash trims whitespace before integer comparison:

# In real bash:
[ "  3  " -ge 2 ] && echo yes  # prints "yes"

Root Cause

In crates/bashkit/src/builtins/test.rs at line 250-252:

fn parse_int(s: &str) -> i64 {
    s.parse().unwrap_or(0)
}

Rust's str::parse::<i64>() does NOT trim leading/trailing whitespace. So " 3".parse::<i64>() returns Err, which falls back to 0. The comparison then evaluates 0 >= 2 → false.

Suggested Fix

fn parse_int(s: &str) -> i64 {
    s.trim().parse().unwrap_or(0)
}

Impact

Medium — Breaks any script using wc output in numeric comparisons. wc pads numbers (via {:>8} format in crates/bashkit/src/builtins/wc.rs line 186), so this affects wc -l, wc -w, wc -c output used with [, test, or [[ integer operators.

Related

• crates/bashkit/src/builtins/wc.rs:186 — padding format
• See also bug: Pipeline stdin not forwarded to user-defined functions #274 (pipeline stdin bug, found in same eval run)

Found In

Eval run 2026-02-25, task script_health_check (Sonnet model).