cvt_cyrusdb utility does not work if /var/lib/cyrus/db is inconsistent

[Dmitry Katsubo]

On 17.08.2011 19:09, Michael Loftis wrote:
> Your answer is there, you check the exit code. If non-zero then there
> was a failure, generic unix scripting rule.
> 
> Bonus points for using mktemp, then mv-ing in the sucessful case and
> cleaning up after yourself in the case of failure (hint, using trap
> can save you lots of code here too).

Michael, thanks for reply.

I agree with you: checking the error code is absolutely OK and should be
performed in scripts. But if you forgive me my persistence, I would like
to be more clear on few points:

** From user's point of view **

- When there is an error and CLI utility just exist, that is not good.
The user cannot understand, what went wrong and cannot react / recover
from error.
- Logging to syslog for CLI utility is not good. How the user can guess
that he needs to check logs?
- The error in the utility was not caused by direct input data (and that
are two files: input and output). The utility should use only the data
it needs to make the operation (on out case that is conversion)
successful. Why /var/lib/cyrus/db/* is needed for conversion? With the
same success utility may terminate if the moon is not in the 1st quarter.

** From programmer's point of view **

Let's look at this function declaration in lib/cyrusdb_berkeley.c:

   static int init(const char *dbdir, int myflags)

>From signature I assume, that the function will return some code in case
of success or in case of error. As there are no code comments (!), I
can't even suppose that the call to this function may never return.

I was often shirking the informatics classes in my school, but I
remember my teacher telling us, that the function should have one entry
point and one exit point. In case when it is not true, it is difficult
to trace down the problems and debug the program in general. Imagine
that in one program module I will launch a timer, that will exit the
program in 5 minutes (a "bomb"). And somebody is debugging another
program's module. And at some moment when you step over, the program
exists. You start thinking about segfault, stack corruption... Re-run
the program, but now it stop in another point! You are angry / shocked /
furious (underline the one you like more).

Sorry if I was too long with my talks.

-- 
With best regards,
Dmitry