exit codes in docs

[Boris 'pi' Piwinger]

Matthias Andree wrote:

> Actually, the whole exit code interface was misdesigned from the moment
> it sprang into being. A program takes standard input and prints its
> finding on standard output. Using exit codes to differentiate between
> "no error" results is wrong.

Hm, can't you use exit codes of grep to see if some
expression did match?

>> I strongly agree here. We are still at some more or less
>> early stage of development. Fixing everything too early
>> creates problems. Changes create problems. So as someone
>> else said: If we do need to make changes, let's do it now.
> 
> My suggestion is remove the "exit code" interface and just use an
> interface along the lines that bogofilter -tv or bogofilter -p provide.

Now that would break interfaces of most people. And it would
make using it much harder, like in the procmail case.

>>> It's not robust, it's not support-friendly and not
>>> the right thing to do. We shouldn't encourage such false use.
>>
>> Suggest a better recipe.
> 
> We already have one in bogofilter(1) (omitting the comments for brevity):
> 
>        :0fw
>        | bogofilter -u -e -p

I don't like that example because of -p. What if you don't
want it?

>>> We can offer a configurable interface with a separate
>>> option,
>>
>> No -t should be good enough, don't you think?
> 
> Not sure what you're aiming at. -t alone as non-configurable interface
> should be OK.

ACK. And I meant that the user-defined output is OK, if -t
is not used, like in bogofilter -v or bogofilter -vvv.

> We need to tell people to expect extensions and handle
> them by pushing "non-understood" codes back to the mail queue.

Or file them as needed.

>>> but I want to have a "canonical interface" that is configuration
>>> invariant and that people use in problem reporting and that should be
>>> the preferred way of using bogofilter results in a script.
>>
>> NACK, this is a good way if you need detailled information,
>> but for the simple question of ham/spam/unsure, this is a
>> step too complicated.
> 
> Making such interfaces configurable is also too complicated.

I agree in general. If we can find some line of output which
is clear enough (yes/no always irritates me, because I
cannot remember the question), I am find with that.
Configuring the output format for the probablities is nice,
though.

pi