Greps this shell runs are served by the built-in engine, single-file lookups included, so an empty result from a served search means the search ran and matched nothing. A search the engine recognises but cannot serve fails as a tool error, not as "no matches": a grep nested in another command (another interpreter's command line, `xargs grep …`, `find … -exec grep … +`, a second grep member of a pipeline), an unsupported flag, a redirect glued to one of the search's own words (`grep -n x>out.txt f.txt` — spell it `grep -n x f.txt > out.txt`) or one it cannot apply to the search it runs, a member that sets state a later member reads, a `cd` the engine cannot track, and a `mahbot` call that is not one plain call of it. Write `mahbot` plainly (`mahbot -V`, `mahbot debug --db board "…"`), never through a launcher or a path: a line that also calls it is served, while a call that is not one plain call of it fails the whole line. A bare `mahbot` is then run by this shell as the product's own copy, from that copy's own full path rather than from any search path — so it always runs, while a path that spells out some other copy of it (`.\mahbot.exe`, `target\debug\mahbot.exe`) is refused here. Left to the platform as written: its own program runs, and you see its outcome, never an empty set from this engine — a search another program owns (`git grep …`), a search in the arguments of a program the engine does not list, a search whose program is spelled with a path, a grep word glued to a `{` or to a redirect operator (`{grep x f.txt`, `grep>x f.txt` — the command word is then not a search), and `find … -exec grep … \;`, whose `\;` stops the engine's reading before the search. Double-quote the search's arguments: `'`, `^` and parentheses are read differently here, and a command using one outside quotes may be refused. A word with two `%` is refused too: `%…%` is expanded before any program runs, quoting or not. A single `%` and every `!` are taken literally.