log.SetOutput doc improvement

[Kevin Chadwick]

"https://godoc.org/log#SetOutput":
"SetOutput sets the output destination for the standard logger."

To me, without clarification, I assumed it would be globally re-directable at
multiple times if desired, but it is only globally effective when ran early from
main.

I don't understand why it is designed this way? If you want package level log
re-direction. I would have thought customisation, a flag switch or multiple
processes communicating would make more sense than the current stdlib design.

Is a log.SetGlobalOutput addition possible?

Rather than people forking stdlib log...!

https://stackoverflow.com/questions/29538668/logging-globally-across-packages


p.s. I currently disagree with errors being an equivocal replacement for log
redirection, as I have seen argued in past threads.

p.p.s. I like err != nil

Regards, Kc

[Ian Lance Taylor]

On Wed, May 6, 2020 at 8:44 AM Kevin Chadwick <m8il...@gmail.com> wrote:
>
> "https://godoc.org/log#SetOutput":
> "SetOutput sets the output destination for the standard logger."
>
> To me, without clarification, I assumed it would be globally re-directable at
> multiple times if desired, but it is only globally effective when ran early from
> main.
>
> I don't understand why it is designed this way? If you want package level log
> re-direction. I would have thought customisation, a flag switch or multiple
> processes communicating would make more sense than the current stdlib design.
>
> Is a log.SetGlobalOutput addition possible?
>
> Rather than people forking stdlib log...!

Sorry, can you show an example of what you mean? As far as I can
tell, you can call log.SetOutput multiple times, and it will affect
all subsequent output of the standard logger, up to the next call to
log.SetOutput.

Logging in general is of course a complicated subject. There have
been some attempts to improve the standard library's logging
capabilities, but they have all foundered because there are too many
different requirements and nobody has figured out how to write one
package that works for everyone. So we have the fairly simple
standard library log package, and there are many third party log
packages that provide different capabilities.

Ian

[Kevin Chadwick]

On 2020-05-06 16:54, Ian Lance Taylor wrote:
> Sorry, can you show an example of what you mean? As far as I can
> tell, you can call log.SetOutput multiple times, and it will affect
> all subsequent output of the standard logger, up to the next call to
> log.SetOutput.

Indeed and I am perfectly happy with the log information I can provide manually
and the performance of locking only in case of an actual error.

Perhaps I left out a critical go routine part that likely explains why it is
technically infeasible? Go routines are so easy to use I kind of forgot that I
was using one, whilst writing.

If you call log.SetOutput within main then it affects all functions and even the
programs it executes if the cmd os.stdout is redirected.

If you use log.SetOutput within a go routine, even if you delay main to make
sure there is no race. Then mains following log.Print and following functions or
executions log output are not redirected?

[Kevin Chadwick]

On 2020-05-06 17:57, Kevin Chadwick wrote:
> If you use log.SetOutput within a go routine, even if you delay main to make
> sure there is no race. Then mains following log.Print and following functions or
> executions log output are not redirected?

If you expect this should work then perhaps I have some other issue currently
that didn't affect my initial experiments. As I am having trouble getting it
working even from main currently.

Sorry

[Kevin Chadwick]

On 2020-05-06 18:03, Kevin Chadwick wrote:
>> If you use log.SetOutput within a go routine, even if you delay main to make
>> sure there is no race. Then mains following log.Print and following functions or
>> executions log output are not redirected?
> If you expect this should work

Seems it does work. I had a channel in a go func blocking somehow, amongst other
things. Converted to a proper function that I am used to using, ran as a go
routine and it's working.

Pretty neat actually.

Sorry for the noise.