exit codes in docs

[Matthias Andree]

Boris 'pi' Piwinger <3.14 at logic.univie.ac.at> writes:

> That is important, I agree. But at some point we need to do
> something. Exit code for unsure has been forgotten at some
> point, it was added now. You argue that exit codes must not
> change, others say, it is more logical the way it is done
> now. Both are valid arguments.

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.

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

> In theory: Yes. In practice: It does work for many people.
> It is *the* standard way of doing it. I know you don't like
> procmail, but many people use it.

This criticism was aimed at our example rather than procmail. People
start jumping in squares if their mail doesn't end up where they want it
to end up, we should not suggest bad usage when we have better to offer.

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

       :0e
       { EXITCODE=75 HOST }

       :0:
       * ^X-Bogosity: Yes, tests=bogofilter
       spam-bogofilter

       :0e
       { EXITCODE=75 HOST }

I'd suggest removing the -u though to avoid registering the same mail
twice.

>> We should remove that example; unless there is protest within 24 hours,
>> I'll remove it.
>
> Count my protest.

OK. I'll have to convince ;-)

>> Then, we should define a machine-readable, extensible interface that
>> prints a single line per mail on stdout and that a user cannot
>> redefine. Casting bogofilter -tv with built-in defaults into concrete
>> comes to mind.
>
> ACK. I don't really understand why -t instead of -tv doesn't
> do it, but never mind.

Probably historic reason, -t was probably used at some time to cut down
-v output, rather than implemented as a standalone option.

>> 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. We need to tell people to expect extensions and handle
them by pushing "non-understood" codes back to the mail queue.

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

-- 
Matthias Andree