[PATCH 2/2] quest: Output errors and meta informations to stderr

[Jeřábek Vladimír]

Thanks for Your answer.

On Thu, 28 Nov 2019 08:29:50 +0000 (UTC), Olly Betts wrote:
 > On Thu, Nov 14, 2019 at 05:20:08PM +0100, Jerabek Vladimir wrote:
 >> ---
 >>  xapian-core/examples/quest.cc | 18 ++++++++++--------
 >>  1 file changed, 10 insertions(+), 8 deletions(-)
 >>
 >> diff --git a/xapian-core/examples/quest.cc 
b/xapian-core/examples/quest.cc
 >> index 9953861d8ce9..831d4a87c5cb 100644
 >> --- a/xapian-core/examples/quest.cc
 >> +++ b/xapian-core/examples/quest.cc
 >> @@ -398,14 +398,14 @@ try {
 >>      Xapian::Query query = parser.parse_query(argv[optind], flags);
 >>      const string & correction = parser.get_corrected_query_string();
 >>      if (!correction.empty())
 >> -    cout << "Did you mean: " << correction << "\n\n";
 >> +    cerr << "Did you mean: " << correction << "\n\n";
 >>
 >>      if (!quiet) {
 >> -    cout << "Parsed Query: " << query.get_description() << endl;
 >> +    cerr << "Parsed Query: " << query.get_description() << endl;
 >>      }
 >>
 >>      if (!have_database) {
 >> -    cout << "No database specified so not running the query." << endl;
 >> +    cerr << "No database specified so not running the query." << endl;
 >
 > I take it your main aim here is to have a machine readable output,
 > but there's a tension between supporting that and having a tool that's
 > easy for humans to use with output that can evolve with time.

Our main aim is in the first patch.

In the second patch we just wanted to put all unexpected output to 
stderr. If you are concerned only about those three lines you mentioned 
we seen these three outputs as not part of main output.
But if you think these three should stay on stdout I can send v2 
addressing this.

 > Splitting the output over stdout and stderr would mean you could no
 > longer just `quest ...|less` or `quest ... > quest.out`.  At least
 > extra tedious typing to redirect stderr to stdout would be needed,

It is also very common to use commands like `quest ...|grep ...` in 
which case you won't get informations about possible errors when 
everything is output to stdout.

 > but you probably also need to worry about the relative ordering due to
 > buffering.

That's why I added the flush.

 > I wonder if a separate tool which produces a machine readable format
 > with an actual specification would be a better approach to this?

Maintaining separate tool just for our case would not be efficient, but 
if this tool would be part of Xapian and maintained by Xapian team, so 
other people could use it, it might be effective solution.

Best regards,
Vladimir