8000 feat: log file support · Issue #40 · mumoshu/variant · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

feat: log file support #40

New issue

Have a question about this project? Sign up for a fr 8000 ee GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
osterman opened this issue Jan 15, 2019 · 7 comments
Open

feat: log file support #40

osterman opened this issue Jan 15, 2019 · 7 comments
Labels
enhancement

Comments

@osterman
Copy link
osterman commented Jan 15, 2019 •
edited
Loading

what

  • support logging to a file (e.g. like tee)

why

  • stdout might be too noisy
  • it would be nice to write to a file for logging purposes while keeping stdout quiet.
@mumoshu
Copy link
Owner
mumoshu commented Jan 15, 2019

I think stdout should just be standard output. We are after all shelling out to other tools (e.g. terraform) that we'd like to see the output.

Yep, it makes sense. I thought I've changed the default behavior to log-to-stderr though, so that only /usr/bin/ls -l output is streamed to the stdout, while the INFO logs are sent to STDERR.

c2f7599

Which version of variant did you try, the latest release or the master(go get -u or whatever)?

@mumoshu
Copy link
Owner
mumoshu commented Jan 15, 2019

capturing the stdout for optionally logging to a file is cool. I like that idea, but not sure how to best reconcile it. with the duplicate output.

Something that works like variant foo bar | tee log.file, right?

@osterman
Copy link
Author

Something that works like variant foo bar | tee log.file, right?

Yep... exactly (although also capturing stderr)

@osterman
Copy link
Author

I'm running https://github.com/mumoshu/variant/releases/tag/v0.10.0, which is a different commit.

@osterman osterman changed the title feat: better output control feat: log file support Feb 7, 2019
@osterman
Copy link
Author
osterman commented Feb 7, 2019

@mumoshu I updated this issue to better reflect the decision we arrived at.

@mumoshu
Copy link
Owner
mumoshu commented Feb 7, 2019

@osterman Thanks!

Would you like to set log-level per destination, like WARN for stdout/stderr(its INFO by default), INFO for the log file 1? Then, do you have any idea what are the canonical flags for the configuration?

What I came up is ./mycmd --loglevel WARN --logtofile mylog.txt=INFO, but not sure if it looks good or not.

@osterman
Copy link
Author
osterman commented Feb 7, 2019

Would you like to set log-level per destination, like WARN for stdout/stderr(its INFO by default), INFO for the log file 1?

Not a strict requirement for first implementation. Just a "nice to have"

./mycmd --loglevel WARN --logtofile mylog.txt=INFO

Filenames can get nasty, especially when working on Windows, etc.

Thus, my suggestion is to always make the predictable key the first one: --logtofile INFO:mylog.txt

I can't think of a great reference example. Only one that comes to mind is socat which does something similar with it's arguments.

https://github.com/craSH/socat/blob/master/EXAMPLES#L159

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@mumoshu @osterman
0