pdfsizeopt is too verbose

Question

pdfsizeopt is too verbose

foolip opened this issue 7 years ago · 9 comments

#126 introduced a problem, namely that the logs are so verbose that Travis doesn't want to load them all. That's because pdfsizeopt is very verbose, but unfortunately it doesn't have a --quiet flag or similar.

@izh1979 @pts, any advice on how to get less verbose output without also hiding errors?

Answer 1 · 2017-12-01T09:34:18.000Z

Is it possible to redirect it to a file or to pipe through some filter? E.g. through a sed script that would cut non-errors? (I'm not familiar with Travis and its limitations.)

Answer 2 · 2017-12-01T09:37:41.000Z

That would be easy, but unfortunately it looks like even info messages are sent to stderr, so to distinguish we'd have to grep in the output.

Answer 3 · 2017-12-01T11:07:05.000Z

It's possible to redirect stderr to stdout by using 2>&1

Answer 4 · 2017-12-01T11:08:26.000Z

As a workaround, until pdfsizeopt receives a --quiet flag, you can redirect both its stdout and stderr to /dev/null: >/dev/null 2>&1, and rely on the exit code to detect success.

Answer 5 · 2017-12-01T11:09:58.000Z

Yeah, I guess that's better, the output is probably rarely interesting, and we can turn it back on if needed for debugging.

Answer 6 · 2017-12-01T11:33:35.000Z

Don't we need it if we run into the missing font issue? Let's at least have a follow-up issue (or keep this open) to improve the setup if upstream improves. Of course, we could also continue to rely on manual reports from @izh1979 that we broke PDF output again. 😊

Answer 7 · 2017-12-01T11:37:33.000Z

Missing fonts will show up in the prince output, not pdfsizeopt.

Answer 8 · 2017-12-02T15:02:15.000Z

FYI The newest pdfsizeopt now has a --quiet flag, as requested.

Answer 9 · 2017-12-04T21:29:58.000Z

Thanks @pts, I used --v=40 in #130 and looked at the result, very good!