**Comment from Launchpad by: Ryan Olson on: 21-05-2015 16:31:34

For me, probably not. I don't want to just filter off all STDERR because if something does in fact go wrong, I want to know about it. If we really do need this output in all circumstances if we're reading input from STDIN, I think my solution of doing a '| grep -v "Reading from STDIN"' is the best bet. Though I think I'd ultimately prefer a positive way to state "read from STDIN" that would tell the tool I know what I'm doing and don't need to see this output.

Not a huge deal either way, I've worked around it here.

**Comment from Launchpad by: Frank Cizmich on: 21-05-2015 15:04:54

Ryan,

Would printing the message to STDERR solve this for you?

**Comment from Launchpad by: Ryan Olson on: 18-05-2015 22:00:37

Only problem is that it started causing some cronspam when we upgraded. I'm zcatting a slow query log file in logrotate and piping to pt-query-digest for Anemometer. If there was a way I could explicitly specify that I want stdin and have this message suppressed that would be great. In the meantime, I'm just "grep -v"ing the output.

**Comment from Launchpad by: Frank Cizmich on: 18-05-2015 21:19:41

Hi Ryan,

It's not a debug statement. This was a compromise "fix". The original problem was that if you gave the tool a file to read, and that file did not exist, it would assume that instead of a file it was a given a DSN (because of a rare use case where a DSN can be passed as a parameter).
In that case the tool would assume that STDIN was the source, and just sit and wait, confusing the user.
So, as to not alter the current parameter format, but still avoid confusing the user, that message is printed.

If this affects you negatively please mention it. Maybe we can find an alternate solution.