[Patch] Let birdc output errors to stderr
Hi, We (Knorrie, andi, and me) realized, that birdc outputs server errors to stdout much like normal server output. When scripting birdc, it can be helpful to have those on stderr instead. Simple use case: birdc CMD >/dev/null If everything is fine, no output at all. If something goes wrong, output! There are a few aspects: 1. Is this useful? Hopefully. If you think this is a studpid idea, pleas explain! 2. Should this be the default (in an upcoming version)? I don't know, how many non humans depend on *all* output going to stdout and neglect stderr? Ignoring stderr IMHO is a design flaw. But well, this is a question of backward compatibility. NOTE: Something should be added to the ChangeLog, so people are not too surprised. 3. If the answer to (2) is "Need backward compatibility": Do we need some --enable-stderr then? Cheers Christian -- www.cosmokey.com
On Mon, Sep 14, 2015 at 01:09:12AM +0200, Christian Tacke wrote:
Hi,
We (Knorrie, andi, and me) realized, that birdc outputs server errors to stdout much like normal server output.
Hi Thanks for the patch, you are right, not using stderr is probably an oversight.
There are a few aspects:
1. Is this useful? Hopefully. If you think this is a studpid idea, pleas explain!
I am not sure if stderr should be used even in interactive mode, but that is hopefully harmless.
2. Should this be the default (in an upcoming version)? I don't know, how many non humans depend on *all* output going to stdout and neglect stderr?
Probably in the next major version.
3. If the answer to (2) is "Need backward compatibility": Do we need some --enable-stderr then?
That seems unnecessary. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
Hi, On Thu, Sep 17, 2015 at 11:01:01 +0200, Ondrej Zajicek wrote: [...]
1. Is this useful? Hopefully. If you think this is a studpid idea, pleas explain!
I am not sure if stderr should be used even in interactive mode, but that is hopefully harmless.
We could add some "!interactive && " to the conditionals, if absolutely needed. But IMHO interactive tools are also allowed to use stderr.
2. Should this be the default (in an upcoming version)? I don't know, how many non humans depend on *all* output going to stdout and neglect stderr?
Probably in the next major version.
That means 1.6? Will you keep the patch in your "for 1.6" queue?
3. If the answer to (2) is "Need backward compatibility": Do we need some --enable-stderr then?
That seems unnecessary.
Good. Overloading options isn't really a good thing. So good! Cheers Christian -- www.cosmokey.com
participants (2)
-
Christian Tacke -
Ondrej Zajicek