Description
When grep is given multiple -e options, POSIX requires all patterns to be combined with OR semantics: a line matches if it matches any of the patterns. just-bash currently applies only the last -e pattern, silently dropping matches for the others.
Reproduction (justbash.dev, also reproduced with just-bash@3.1.0 on Node 22 / Bun 1.3.5)
printf 'aaa Q1\nbbb\nccc Q4\n' > t.txt
grep -e 'Q1' -e 'Q4' t.txt
Expected (GNU grep / POSIX)
Actual
Exit code is 0 and stderr is empty in both cases, so there is no signal that matches were dropped.
Why this matters for agent use cases
Since the command "succeeds" with plausible output, an LLM agent has no way to notice the missing matches — it will typically conclude the data simply doesn't contain them and carry on with a wrong analysis. A hard error would be recoverable (the model retries); a silent partial result is not.
Reference: POSIX grep spec, -e pattern_list: "Specify one or more patterns to be used during the search for input. […] multiple -e and -f options are accepted and grep uses all of the patterns it is given while matching input text lines." — the fix is presumably to collect all -e values and join them as alternation, rather than keeping the last.
Workaround: grep -E 'Q1|Q4' behaves correctly.
Thanks for the project — the agent-oriented design (in-memory fs, network off by default, re2js) is exactly what we needed. Happy to provide more test cases if helpful.
Description
When
grepis given multiple-eoptions, POSIX requires all patterns to be combined with OR semantics: a line matches if it matches any of the patterns. just-bash currently applies only the last-epattern, silently dropping matches for the others.Reproduction (justbash.dev, also reproduced with
just-bash@3.1.0on Node 22 / Bun 1.3.5)Expected (GNU grep / POSIX)
Actual
Exit code is
0and stderr is empty in both cases, so there is no signal that matches were dropped.Why this matters for agent use cases
Since the command "succeeds" with plausible output, an LLM agent has no way to notice the missing matches — it will typically conclude the data simply doesn't contain them and carry on with a wrong analysis. A hard error would be recoverable (the model retries); a silent partial result is not.
Reference: POSIX grep spec,
-e pattern_list: "Specify one or more patterns to be used during the search for input. […] multiple-eand-foptions are accepted and grep uses all of the patterns it is given while matching input text lines." — the fix is presumably to collect all-evalues and join them as alternation, rather than keeping the last.Workaround:
grep -E 'Q1|Q4'behaves correctly.Thanks for the project — the agent-oriented design (in-memory fs, network off by default, re2js) is exactly what we needed. Happy to provide more test cases if helpful.