Hallvard B Furuseth wrote:
> hyc(a)symas.com writes:
>> Just redirect stdin, and the meter will automatically turn itself off.
> It was stderr, not stdin - which after all can be the ldif.
> Stdout is better.
No, you misunderstand.
Redirecting stderr (or stdout) merely sends the progress info to that
destination. Piping input on stdin will turn it off, so there's no progress
info to redirect.
No, the code only enables the meter if stdout (was: stderr) is a tty, so
redirecting it anywhere disables it. The meter was enabled both by
"slapadd -l file" and "slapadd < file", but "cat file |
disable it. IMHO not exactly an obvious way..
An option sounds more and more like the solution, what about "-m" for
meter? Though I'm not sure whether I prefer that it should be enabled
by default and the option disable it, or the other way around..
Writing progress to stderr is the correct thing to do, because
info that isn't meant to be saved. Checking whether stdout is redirected or
not is fine, but writing progress info to stdout is not.
For programs that produce real output (slapcat, ldapsearch) this might
be true, but for those that don't (slapadd, slapd) I totally disagree.
Stderr is for errors, not chatty progress or debug messages. I always
hate it when the error messages gets burried in lots of noice.
My preference is to have progress and debug messages on stdout, enabled
by options or at least possible to disable by options. Real output must
be possible to send to a file specified as argument, to separate it from
the progress and debug noice. Stderr is for error messages, and
possibly out-of-band messages.