fprintf(stderr,...) output in GSL routines (gsl_rng_env_setup)

[Peter Teuben <teuben at astro dot umd dot edu>]

A philosphical question:  I have been using a few gsl routine and replacing some
of my own old codes. I like gsl, i certainly like to see more! But one thing
that I found a bit of a nuisance is that there is sometimes some surprising
fprintf(stderr,.....) calls in some routines. Actually, I only ran into one so
far, the RNG setup routine, gsl_rng_env_setup.

I happen to prefer to pass parameters via functions, not via environment
variables, but that can be solved with putenv(), which is what i had to
do. But this results in output like
GSL_RNG_TYPE=ran3
GSL_RNG_SEED=10880933
and now my scripts that do a lof of simulations and set the rng via
the system clock [using times()], so i now suddenly get a lot of lines
of output!

In the above case, the user can always use gsl_rng_default_seed,
and gsl_rng_name(), as shown in the example in Section 16.6, so I wondered
why this output was needed at all. They occur in fairly low level routines,
and potentially can interfer with client software, without the client
having a chance to silence it more.

What we did in our own software was to define a global debug level
(via the DEBUG environment variable or via a set_debug_level() function)
and all fprintf(stderr,....) was replaced with dprintf(req_level,.....). So,
if the user did nothing, it became equivalent to an fprintf(stderr,...),
else it was never shown unless debug=1 or debug=2 was used.

btw, dprintf() is now a bad name, it appears to have been hijacked by gnu/libc?
judging from newer /usr/include/stdio.h files.

- peter