quiet mode (-q) should suppress "no matches" error

[Karl Fogel]

Currently bzr-search treats no matches as an error, even when -q is given:

  $ bzr search -q string-that-will-not-match
  bzr: ERROR: No matches were found for the search [u'string-that-will-not-match'].
  $

Getting no hits is a very common occurence. I'm not sure it should be an error
even by default; IMHO it definitely shouldn't print an error when -q is passed.

Yes, this would be easy to patch, and if I get a chance I will. I just wanted to
file the bug before I forgot.

[Robert Collins (lifeless)]

I'm not sure I agree here. Should bzr search -q foo not output its requested results?

-q to me isn't 'have no ui' its, 'show no chatter'. A complete lack of results isn't chatter, its the result.

[Karl Fogel (kfogel)]

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 :-).

[Robert Collins (lifeless)]

On Fri, 2009-06-05 at 23:57 +0000, Karl Fogel wrote:
> 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 all bzr programs, stderr output doesn't mean error, it means 'output
that wasn't the thing itself'. Progress bars, chatter, password prompts
and errors go to stderr to make scripting easier.

For batching, no matches should have an exit code of non-zero already,
so simply testing for ?$ != 0 should let you do flow control. If you
need more precise flow control I'd be delighted to put that in using
bzr's standard conventions.

> 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.

$ grep foo bar
grep: bar: No such file or directory

I'm entertaining the idea of showing no output on a successful query
that finds no matches; however that is orthogonal to -q, as you note
below for grep.

> 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 :-).

Well the -q flag is global; its inherited from the bzr command framework
- I'm not sure the description is really complete as it stands. What use
'diff -q' if you can't see the diff? I really consider -q as 'drop the
chatter', not 'drop the output'. And we agree that no matches is not
chatter :).

If what you really want is 'no output on no matches' and we can drop the
-q discussion, that might be more useful - you made some good points
vis-a-vis UI, but you haven't managed to do that with respect to -q
itself : I believe bzr-search is honouring -q for bzr at the moment
[mainly because bzr-search has no chatter].

-Rob

[Karl Fogel (kfogel)]

Good point: a no-output-on-no-matches flag would solve this, and I'd shut up :-).

Re 'grep foo bar': that's an assertion that bar exists, but not an assertion that foo exists. When you search for something, it is interesting if the place you're searching for it doesn't exist (!), but not so interesting if the thing you're searching for in that place doesn't exist (after all, it could just be somewhere else, or not exist at all). In the current discussion, 'grep foo bar' when bar does not exist is equivalent to doing a 'bzr search' before the index has been built, or when the current working directory is not a bzr-controlled tree at all.

[Karl Fogel (kfogel)]

Ah, I see you weren't necessarily proposing a new flag, just considering changing the default behavior, got it.

So: from my perspective, no-output-on-no-matches is a good default behavior, yeah. I agree it's orthogonal to -q.