shell(touch): report --date=, --reference= and --time= as unsupported options

[robobun]

Problem

• In the Bun shell, touch --date=x f, touch --reference=f g and touch --time=atime f fail with touch: illegal option -- date=x (reference=f, time=atime), as if the option did not exist. The bare spellings of the same options (touch --date x f) already fail with touch: unsupported option, please open a GitHub issue -- --date.
• parse_long in src/runtime/shell/builtin/touch.rs compares the whole argument against --date, --reference and --time, so --date=x matches nothing, parse_long returns None, and the shared parser (parse_one_flag in src/runtime/shell/interpreter.rs) falls through to short option parsing of -date=x, whose first byte - is reported as an illegal option.
• Exit code 1 is already right; only the stderr text is wrong. The same comparison was in the Zig version, so this is not a port regression. Found by reading the option table, not from a report.

Fix

• parse_long splits the argument at its first = into a name and an optional value and matches the name, so --date x and --date=x are both reported as the unsupported --date (likewise --reference=FILE and --time). The reported names are unchanged.
• --no-create takes no value, so its arm only matches when there is none: --no-create=x is not a spelling of it and stays an illegal option (GNU touch rejects it too).
• Why this is right: --option VALUE and --option=VALUE are the two spellings getopt_long accepts for an option that takes a value, and these three take one in GNU touch, so both spellings name the same option and should get the same answer. The two messages mean different things to the user: "unsupported" says the option is known and not implemented (and asks for an issue), "illegal" says it does not exist.
• Scope: the =VALUE split is done in touch's own table, the same way shell: report --name=value spellings of unsupported builtin options as unsupported #39223 does it for mkdir --mode=; these are the only two FlagParser implementations with long options (cat and cp have none). Doing the split once in parse_one_flag instead would be the tidier end state, but parse_one_flag, the FlagParser trait and mkdir's parse_long are each being edited by open PRs right now (shell: treat a lone - as an operand in the builtin option parsers #39214, shell: accept -- end-of-options delimiter in builtins #33995, shell: name the rejected flag in the builtins' illegal option errors #39230, shell(mkdir): accept --verbose instead of the misspelling --vebose #39221, shell: report --name=value spellings of unsupported builtin options as unsupported #39223), so this PR stays inside touch.rs; a later consolidation deletes this hunk and keeps the test rows.
• Stacked on shell(touch): name --time in its unsupported option message #39219 (its commit is the first of the two here): that PR fixes the name the bare --time arm reports and adds the table test this PR extends. If shell(touch): name --time in its unsupported option message #39219 lands first this rebases to just the second commit.
• Verified with test/js/bun/shell/commands/touch.test.ts: the table gains --date=@0, --date=, --reference=other and --time=atime, plus a case checking --no-create=1 is still classified as an illegal option (only the classification is pinned: shell: name the rejected flag in the builtins' illegal option errors #39230 changes which bytes that message quotes, and this case passes either way). On the released bun (1.4.0) the four =VALUE cases fail (and shell(touch): name --time in its unsupported option message #39219's --time case); on this branch all 16 cases pass.
• Also ran test/js/bun/shell/exec.test.ts (pins touch --help as an illegal option, unaffected because --help is not in the table) and the exit codes block of test/js/bun/shell/bunshell.test.ts against the debug build; both pass.

Background

• The shell builtins touch, mkdir, cat and cp parse their flags through the FlagParser trait in src/runtime/shell/interpreter.rs. For an argument starting with --, parse_one_flag first offers the whole argument to the builtin's parse_long; if that returns None it treats the bytes after the first - as a cluster of short flags, which is where the illegal option -- date=x text comes from.
• A builtin returns ParseFlagResult::Unsupported(name) for an option it recognizes but does not implement; Builtin::fail_parse formats name (a literal chosen by the builtin, not the argv entry) into the unsupported option, please open a GitHub issue -- <name> line and exits 1. IllegalOption produces the illegal option -- <bytes> line, also exit 1.
• touch is a shell builtin on every platform (only cat and cp defer to the system binary on POSIX), so the test needs no platform gating.

[robobun]

^{Updated 6:52 PM PT - Aug 15th, 2026}

✅ @robobun, your commit b10a1b4c34d811d7cb7a65c120c0721852cbc3d5 passed in Build #98949! 🎉

---

🧪   To try this PR locally:

bunx bun-pr 39227

That installs a local version of the PR into your bun-39227 executable, so you can run:

bun-39227 --bun

[coderabbitai]

Warning

Review limit reached

@robobun, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 22 minutes

Limit details: You’ve used all 5 included reviews currently available under your plan.

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: b2ebbe64-4014-4d48-90fe-15eec08e9fdc

📥 Commits

Reviewing files that changed from the base of the PR and between a42889a and b10a1b4.

📒 Files selected for processing (2)

• src/runtime/shell/builtin/touch.rs
• test/js/bun/shell/commands/touch.test.ts

---

_{Comment @coderabbitai help to get the list of available commands.}

[robobun]

Status: reproduced and fixed.

• Reproduced on the released bun 1.4.0 with test/js/bun/shell/commands/touch.test.ts: the --date=@0, --date=, --reference=other and --time=atime cases fail with touch: illegal option -- date=@0 (etc.) instead of the unsupported option message.
• With this branch's debug build all 16 cases in that file pass, as do test/js/bun/shell/exec.test.ts and the exit codes block of test/js/bun/shell/bunshell.test.ts.
• Stacked on shell(touch): name --time in its unsupported option message #39219 (first commit); the second commit is this PR's change. The PR body's Scope bullet covers why the split lives in touch.rs for now rather than in the shared parser.

[claude]

LGTM — small, well-scoped error-message fix with a table test covering every arm.

What was reviewed:

• parse_long now splits on = before matching value-taking options; split_once_char returns None when no = is present so bare --date still matches.
• --no-create is checked before the split, so --no-create=1 still falls through to illegal option — pinned by the new test.
• Test follows sibling test/js/bun/shell/commands/*.test.ts conventions (TestBuilder, describe.concurrent, ensureTempDir, exit-code + stderr assertions).

Extended reasoning...

Overview

This PR touches src/runtime/shell/builtin/touch.rs (the parse_long implementation of the FlagParser trait) and adds test/js/bun/shell/commands/touch.test.ts. The change makes touch --date=x, --reference=x and --time=x report as unsupported options (matching the existing behavior for the space-separated --date x spelling) instead of falling through to short-flag parsing and reporting illegal option -- date=x. It also carries forward the stacked #39219 fix where --time previously reported --reference=FILE due to a copy-paste. Only stderr text changes; exit code was already 1.

Security risks

None. This is pure error-message classification in a shell builtin's flag parser. No user input reaches a syscall differently than before — every path through parse_long still returns Unsupported or None, both of which cause the command to exit 1 before any filesystem operation. split_once_char is a bounds-safe in-tree helper over &[u8].

Level of scrutiny

Low. The diff is ~10 lines of Rust changing which literal string an already-failing command prints, plus a new test file. No control-flow, memory, or lifetime changes. The --no-create exact-match is deliberately kept before the split (it takes no value in GNU touch), and the test pins that --no-create=1 remains an illegal option. I confirmed bun_core::strings::split_once_char exists and returns Option<(&[u8], &[u8])>, so .map_or(flag, ...) correctly preserves the no-= case. I also confirmed parse_one_flag in interpreter.rs only calls parse_long for args with the -- prefix, so the split is always operating on a well-formed long option.

Other factors

The test file mirrors the structure of sibling files in test/js/bun/shell/commands/ (TestBuilder, .ensureTempDir(), .exitCode(), .doesNotExist(), describe.concurrent). The table covers every long and short option arm plus the =VALUE variants and the empty-value --date= edge, and a negative case for --no-create=1. The PR description explains the stacking on #39219 and verifies the test fails on released Bun and passes on the branch. No outstanding reviewer comments.

[github-actions]

This PR may be a duplicate of:

1. shell(touch): name --time in its unsupported option message #39219 - Makes the identical fix to the same --time arm of parse_long in src/runtime/shell/builtin/touch.rs and adds the same new test/js/bun/shell/commands/touch.test.ts, making it a strict subset of this PR.

🤖 Generated with Claude Code

[robobun]

Not a duplicate of #39219: this PR is stacked on it. The first commit here is #39219's commit (the --time arm's name), which is why that PR shows up as a subset. The second commit is the change this PR is for: --date=X, --reference=X and --time=X were reported as illegal options instead of as the unsupported --date / --reference / --time, which #39219 does not touch (it only changes the literal the bare --time arm reports). Once #39219 lands this rebases down to the second commit.

[robobun]

Heads up: the --no-create=1 test here pins touch: illegal option -- no-create=1. That text comes from the off-by-one in parse_short (it slices the cluster at 1 + i, one past the rejected byte), which #39230 fixes; after that change an unknown --long option is reported as touch: illegal option -- -, like rm/ls/mv already do, so whichever of the two lands second will fail this assertion. Matching on the prefix (/^touch: illegal option -- /) plus the exit code and doesNotExist("file") would keep this test valid either way.

[robobun]

Heads up: #39223 has been reworked to handle --name=value in the shared parse_one_flag (interpreter.rs), so touch --date=x, --reference=f and --time=atime get the unsupported message there without any change to touch's parse_long. If that lands, the touch.rs part of this PR becomes unnecessary; the table test here is still useful. One difference to be aware of: with the dispatcher-level change --no-create=1 is reported as unsupported --no-create too (the option is unimplemented in any spelling), so the --no-create=1 is still illegal case here would disagree with it.

[claude]

LGTM — small, correct error-message fix with a table test that pins each case.

What was reviewed:

• parse_long now splits on the first = via bun_core::strings::split_once_char and matches the name; --no-create's value.is_none() guard keeps --no-create=1 falling through to illegal — matches GNU touch.
• The stacked --time arm fix (was reporting --reference=FILE) is included.
• Test uses the shell TestBuilder harness with ensureTempDir/doesNotExist/exit-code checks; .stderr(callback) is a supported overload; the --no-create=1 case pins only the illegal option -- prefix so it stays green regardless of #39230's ordering.

Extended reasoning...

Overview

Two files: src/runtime/shell/builtin/touch.rs (the parse_long body only) and a new test/js/bun/shell/commands/touch.test.ts. The Rust change splits the incoming long-option argument at its first = into (name, value) and matches on name, so --date=x, --reference=x and --time=x are recognized as the same unsupported options as their bare spellings instead of falling through to the short-flag path and being reported as illegal. The --time arm's copy-paste literal (--reference=FILE) is fixed to --time (the stacked #39219 commit). --no-create gains a value.is_none() match guard so --no-create=VALUE continues to fall through as illegal, matching GNU touch.

Security risks

None. This affects only which of two error messages is printed on an already-failing path (exit code was already 1). No new syscalls, no memory management, no user-controlled data reaching allocation or filesystem paths.

Level of scrutiny

Low. The change is a ~15-line rewrite of a static match table in an error-message path of a shell builtin. I verified bun_core::strings::split_once_char returns (before, after) at the first delimiter or None, so --date (no =) still matches, --date= yields ("--date", "") and matches, and --no-create=1 yields Some so the guard rejects it and it falls through to _ => None → short-flag illegal. No other callers of parse_long are affected (this is touch's own FlagParser impl).

Other factors

The new test file follows the existing test/js/bun/shell/commands/*.test.ts conventions (createTestBuilder, ensureTempDir, .quiet(), .exitCode(1), .doesNotExist("file")), covers all 15 known-but-unsupported spellings plus the negative --no-create=1 case, and asserts exact stderr for each. The .stderr(callback) overload used for the illegal-option case exists in test_builder.ts. The comment-cop bot's feedback about a paragraph-long comment was addressed in b10a1b4 — the current code has a one-line comment and expresses the takes-no-value rule as a match guard. The remaining timeline notes are cross-PR merge-order coordination (#39223, #39230), not correctness issues with this diff, and the test was already loosened to survive #39230. No CODEOWNERS entry for shell paths.