Comment 2 for bug 381282

The practical consequence is that the program becomes more difficult to batch, because now the driver cannot assume that output on stderr means something went wrong (and if the output were moved to stdout, then the driver would not be able to assume that output means there are some matches). Instead, the driver has to parse the results just to learn there were no matches.

For humans users, it also violates the Principle of Least Surprise: people who run command-line search programs generally expect grep-like behavior, which is to print nothing if there were no hits. In fact, with 'grep' itself, you don't even have to pass -q for that; it's the default behavior. Same with 'find'. I'm pretty sure most of the other command-line search tools in widespread use (at least on Unix, the only environment I know) work that way; can you think of any counterexamples? ('whatis' is one, but it does not have a -q flag, so we don't know how it would behave if it did.)

As a user, I now have to think harder when I use bzr-search. I can't just glance quickly at my screen and see if my prompt came back (which requires a few milliseconds of thought). Instead, I have to read and semi-grok the output to know whether there were any hits at all (closer to half a second).

Finally:

the help text for the -q flag says "Only display errors and warnings." Lack of hits is not an error or a warning; it's a perfectly normal result. Indeed, it may be the common case. I think the -q flag's current description is great; I just wished the flag actually behaved that way :-).