Bat: Silence warnings

Created on 10 Feb 2020  路  3Comments  路  Source: sharkdp/bat

I use bat to preview files in fzf. When bat is called on a binary file, it will display a warning:

$ bat foo.pdf 2> /dev/null
[bat warning]: Binary content from file 'foo.pdf' will not be printed to the terminal (but will be present if the output of 'bat' is piped). You can use 'bat -A' to show the binary file contents.

As you can see, there is no way to silence this warning. For my specific use case, using bat as a "previewer", I would rather it be silent than that it displays an "error". Would it be a good idea to make it possible to silence warnings somehow?

In terms of implementation, I was thinking one could implement the warnings of bat such they are directed to stderr (seemingly, they are directed to stdout now?). In that way, users that don't need the warnings, can redirect stderr to /dev/null, without a lot of changes to bat itself. Alternatively, one could add a new switch to bat, that makes it less verbose in case of warnings.

edit:

I'm not sure wether it's customary to print warnings to stderr, btw.

feature-request good first issue

Most helpful comment

Thank you for your feedback.

When bat is called on a binary file, it will display a warning:

This only happens if you disable the "header" component in bats output style. We do this because there would be no output at all for binary file otherwise, which could be confusing if a user unknowingly prints a binary file or calls bat on multiple files.

I am assuming that you have a config file which sets a different default style (or you used the BAT_STYLE environment variable). In this sense, you can "disable" the warning by re-enabling the header style component. That's not a real "fix" of course, more intended as an explanation.

In terms of implementation, I was thinking one could implement the warnings of bat such they are directed to stderr (seemingly, they are directed to stdout now?)

Yes, this is on purpose. We print warnings to stdout because they would interfere with paging support otherwise. They would be printed "in the background" and would not be visible in the pager output.

I guess we could print warnings to stderr if we are not piping to a pager, which would at least solve this particular use case.

Alternatively, one could add a new switch to bat, that makes it less verbose in case of warnings.

That's always an option, but I'd like to avoid introducing a new command-line option, if possible.

All 3 comments

Thank you for your feedback.

When bat is called on a binary file, it will display a warning:

This only happens if you disable the "header" component in bats output style. We do this because there would be no output at all for binary file otherwise, which could be confusing if a user unknowingly prints a binary file or calls bat on multiple files.

I am assuming that you have a config file which sets a different default style (or you used the BAT_STYLE environment variable). In this sense, you can "disable" the warning by re-enabling the header style component. That's not a real "fix" of course, more intended as an explanation.

In terms of implementation, I was thinking one could implement the warnings of bat such they are directed to stderr (seemingly, they are directed to stdout now?)

Yes, this is on purpose. We print warnings to stdout because they would interfere with paging support otherwise. They would be printed "in the background" and would not be visible in the pager output.

I guess we could print warnings to stderr if we are not piping to a pager, which would at least solve this particular use case.

Alternatively, one could add a new switch to bat, that makes it less verbose in case of warnings.

That's always an option, but I'd like to avoid introducing a new command-line option, if possible.

Thanks for your detailed reply! I

In this sense, you can "disable" the warning by re-enabling the header style component. That's not a real "fix" of course, more intended as an explanation.

I'm pretty much satisfied with your solution, re-enabling headers indeed rids of the warning. My bad for not noticing that.

I guess we could print warnings to stderr if we are not piping to a pager, which would at least solve this particular use case.

I won't have time to implement this in the considerable future (I don't know rust), but might one day implement this, if you think there is no better solution.

(You can close this if you're not super interested, I'm largely satisfied with how things stand now)

Thought about this again. I think we'll leave the current behavior. Changing from stdout to stderr when not printing to a pager could lead to other surprising behaviors.

Was this page helpful?
0 / 5 - 0 ratings