Skip to content
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

Add a CustomString type to allow unescaped output. #101

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

kormat
Copy link

@kormat kormat commented Aug 8, 2016

When trying to print multi-line (or otherwise formatted) messages, the
fact that all strings are escaped becomes a problem. For example:

func PanicLog() {
    if err := recover(); err != nil {
        log.Crit("Panic", "stack", string(debug.Stack()))
    }
}

The stack trace becomes a single line, with all \n's and \t's escaped.
With this new type, the central line becomes:

log.Crit("Panic", "stack", log.CustomString(debug.Stack()))

and now it formats in a readable way. Any CustomString values are
surrouneded by triple backticks to it easier to see where they
start/end. An example output is viewable here:
https://gist.github.com/kormat/10e09e4dcfef0115c65fcdc20c98297e


This change is Reviewable

@ChrisHines
Copy link
Collaborator

Triple back ticks are not part of what is currently understood as the logfmt format and are not understood by the existing Go logfmt parsers in github.com/kr/logfmt and github.com/go-logfmt/logfmt. I doubt that the logfmt parsers written in other languages will parse triple back ticks either.

A log15.CustomString that itself contains triple back ticks would result in an ambiguous log entry.

Using the proposed log15.CustomString type would help human readability, but harm machine readability.

@kormat
Copy link
Author

kormat commented Aug 8, 2016

Hmm, k. Looking at kr, i don't see any way to support making multi-line output readable for humans. Assuming that is the case, do you think it would be possible to get it merged anyway, with a warning saying that this won't work for machine parsing? We use multi-line logging a Lot in our code.

@kormat
Copy link
Author

kormat commented Aug 8, 2016

It wouldn't be hard to make it machine readable (e.g. by prefixing all of the lines with something like >), just not within logfmt.

@kormat
Copy link
Author

kormat commented Aug 8, 2016

I've updated the PR and gist with a machine-readable representation.

When trying to print multi-line (or otherwise formatted) messages, the
fact that all strings are escaped becomes a problem. For example:

```
func PanicLog() {
    if err := recover(); err != nil {
        log.Crit("Panic", "stack", string(debug.Stack()))
    }
}
```
The stack trace becomes a single line, with all \n's and \t's escaped.
With this new type, the central line becomes:
```
log.Crit("Panic", "stack", log.CustomString(debug.Stack()))
```
and now it formats in a readable way.

CustomString multi-line values are rendered with a leading `> `, to
enable machine parsing. An example output is viewable here:

https://gist.github.com/kormat/10e09e4dcfef0115c65fcdc20c98297e
@kormat
Copy link
Author

kormat commented Aug 21, 2019

Rebased and updated. We've been using this for the last 2 years, and have tooling which parses the output.

@davisford
Copy link

LGTM - I want an option to print un-escaped strings to the console for many reasons.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants