Skip to content

Logging to stdout seems to be disabled #358

New issue

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

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

Closed
azerupi opened this issue Jun 24, 2017 · 3 comments · Fixed by #369
Closed

Logging to stdout seems to be disabled #358

azerupi opened this issue Jun 24, 2017 · 3 comments · Fixed by #369
Labels
A-CLI Area: CLI C-bug Category: A bug, incorrect or unintended behavior E-Easy Experience: Easy
Milestone

Comments

@azerupi
Copy link
Contributor

azerupi commented Jun 24, 2017

Since some time, mdBook doesn't log anything to stdout anymore. Users don't get any feedback from mdBook, which is not good...

Related to #355

@azerupi azerupi added A-CLI Area: CLI E-Easy Experience: Easy C-bug Category: A bug, incorrect or unintended behavior labels Jun 24, 2017
@azerupi azerupi added this to the 0.1.0 milestone Jun 24, 2017
@budziq
Copy link
Contributor

budziq commented Jun 24, 2017

Well it is not really disabled we just don't log messages on Error level which are displayed by default. If we set RUST_LOG=info or debug we see some additional logs. It depends what you would like to achieve.

Cargo for instance uses dual logging system. env_logger like mdBook does for its backend/library part (that is controlled by RUST_LOG env var). And termcolor based colored output to stdout for the binary frontend app that is controlled by --verbose and --quiet cmd switches.

We can either:

  • emulate cargo's split logging system
  • raise the default visible loggin level to info
  • use println / termcolor where we want guaranteed output to stdout.

but firstly we would need to know which logs would need to be shown by default.

@azerupi
Copy link
Contributor Author

azerupi commented Jun 26, 2017

Cargo for instance uses dual logging system.

Interesting. I assume this is to split the output into messages for the devs and messages for the users, which is nice. We could go that route if it doesn't add a lot of complexity. Otherwise we should set the logging level to info I think, and make sure that all the messages for ìnfo, warnand errorare directed at users. We can keepdebugandtrace` for development purposes.

Having coloured output would be a nice addition too.

@budziq
Copy link
Contributor

budziq commented Jun 26, 2017

Having split logging would certainly add complexity cargo seams to prefer logging to user (with several variants of their shell.warn as opposed to seldom used warn!).

I would go with info bumping the level to info and see how do we like it. Also colored output is pretty trivial to add with https://github.com/seanmonstar/pretty-env-logger (I helped clean its docs some time ago).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-CLI Area: CLI C-bug Category: A bug, incorrect or unintended behavior E-Easy Experience: Easy
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants