FAQ
Hi,

I was searching for a way to set the log output directory and found how to
do it when reading the source code.
The log_dir flag seems to be undocumented.
https://github.com/golang/glog/blob/master/glog_file.go#L41

On a related note:
I think it would be nice to expose the settings directly in the package,
instead of forcing the usage of the `flag` package.

/GeertJohan

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Geert-Johan Riemer at Aug 13, 2013 at 9:50 pm
    Rob Pike fixed this by adding documentation
    https://github.com/golang/glog/commit/c6f9652c7179652e2fd8ed7002330db089f4c9db

    Thanks.
    On Monday, 12 August 2013 09:38:50 UTC+2, Geert-Johan Riemer wrote:

    Hi,

    I was searching for a way to set the log output directory and found how to
    do it when reading the source code.
    The log_dir flag seems to be undocumented.
    https://github.com/golang/glog/blob/master/glog_file.go#L41

    On a related note:
    I think it would be nice to expose the settings directly in the package,
    instead of forcing the usage of the `flag` package.

    /GeertJohan
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • David Chung at Aug 22, 2013 at 11:29 pm
    There's one more caveat... and perhaps another argument for exposing the
    settings directly rather than via flags:

    The log_dir flag will have no effect, if glog is called before the
    flag.Parse(), because log directories are created via the
    onceDirs.Do(createLogDirs). This can happen if a program depends on code
    in some library package and that library package calls glog to log in its
    init() block. During init(), the logDir flag is not parsed (with "" as
    default), and logs are sent to a os.TempDir() which the user doesn't know.
      So it will just look like it's not logging. Logging calls after
    flag.Parse() will not create the log dir as specified because of the
    sync.Once.

    Thanks.

    On Tuesday, August 13, 2013 2:50:51 PM UTC-7, Geert-Johan Riemer wrote:

    Rob Pike fixed this by adding documentation

    https://github.com/golang/glog/commit/c6f9652c7179652e2fd8ed7002330db089f4c9db

    Thanks.
    On Monday, 12 August 2013 09:38:50 UTC+2, Geert-Johan Riemer wrote:

    Hi,

    I was searching for a way to set the log output directory and found how
    to do it when reading the source code.
    The log_dir flag seems to be undocumented.
    https://github.com/golang/glog/blob/master/glog_file.go#L41

    On a related note:
    I think it would be nice to expose the settings directly in the package,
    instead of forcing the usage of the `flag` package.

    /GeertJohan
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Rob Pike at Aug 23, 2013 at 12:19 am
    Don't log in init. You should avoid I/O during initialization in any case.

    As the docs make clear, glog is just an export of a Google-internal
    package. It's there because many people have asked for "leveled"
    logging and the package shows one efficient way to provide it; the
    public packages I've seen provide no way to avoid evaluating the
    arguments to the logging call. Plus it's got a couple of nice
    features, like -vmodule. And it's thoroughly tested, thread-safe, and
    robust, and does things like file rollover at midnight. It's
    production-ready.

    But the package is designed for Google, and in particular to match in
    minute detail the external behavior (files, flags, etc.) of an extant
    C++ logging package. It's unlikely to be a perfect fit for just about
    anyone else, although it's quite usable.

    The package is what it is, and it will evolve only as the internal
    Google package evolves.

    If you want something different, it's open source and you are free to
    take the source or its ideas and provide an alternative. As I've said
    before, I hope someone will.

    -rob

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • David Chung at Aug 23, 2013 at 4:38 am
    It's quite a lovely package actually. As a Xoogler who used to work with
    the c++ versions of the gflags and glog libraries, these packages really
    make a newcomer to go feel at home.

    As it turns out, we have code in the init of one package calling some
    public function in another package. That function logs a warning for some
    error conditions. Because it was called in the init in another package
    (not knowing that the function tries to log or do I/O) and the error hit
    and triggered a logging call, so the logs were written only in the
    os.TempDir and not in the specified log directory. It took a little bit
    of digging to figure out, but overall it was a good learning experience on
    the best practice dealing with package initializations via init() and
    responsibilities in error handling.



    On Thu, Aug 22, 2013 at 5:19 PM, Rob Pike wrote:

    Don't log in init. You should avoid I/O during initialization in any case.

    As the docs make clear, glog is just an export of a Google-internal
    package. It's there because many people have asked for "leveled"
    logging and the package shows one efficient way to provide it; the
    public packages I've seen provide no way to avoid evaluating the
    arguments to the logging call. Plus it's got a couple of nice
    features, like -vmodule. And it's thoroughly tested, thread-safe, and
    robust, and does things like file rollover at midnight. It's
    production-ready.

    But the package is designed for Google, and in particular to match in
    minute detail the external behavior (files, flags, etc.) of an extant
    C++ logging package. It's unlikely to be a perfect fit for just about
    anyone else, although it's quite usable.

    The package is what it is, and it will evolve only as the internal
    Google package evolves.

    If you want something different, it's open source and you are free to
    take the source or its ideas and provide an alternative. As I've said
    before, I hope someone will.

    -rob
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedAug 12, '13 at 7:38a
activeAug 23, '13 at 4:38a
posts5
users3
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase