Add command-line parameter to silence non-error log messages #1194
Comments
dhersz
added
the
enhancement
|
I agree, this is annoying. This same issue came up with the gtfs-rt-validator - MobilityData/gtfs-realtime-validator#98. From what I recall it's a quirk of the current Java logging framework being used. Even if you log something as "error" or "debug", there is effectively one pipe coming out of the logging framework, and by default this gets output to stderr. You can configure the framework to redirect everything to stdout instead, but there isn't an option to split for example "debug" to stdout and "error" to stderr. So IIRC the only way to fix this is to switch logging frameworks. |
|
To be fair, I think that all these logs should be piped to stderr, and not to to stdout, because the output of the validator are the html and json files, not the log messages. My suggestion would only control which messages are outputted, not where. I was thinking, for example, that this line that outputs how long validation took, could be wrapped in a |
|
@dhersz Thanks for the feedback! Sounds like your approach to switching parts of the log on/off is similar in concept to #256? I should also note that it's been a while since I've looked at the logging implementation in this project, so it's worth doing a review there to see if the same limitations apply here that we saw in MobilityData/gtfs-realtime-validator#98. |
|
That's exactly it. Sorry for opening this issue then, I had searched for "quiet" but somehow forgot search for "verbose". Should we just close this issue and keep the discussion on the other one you linked to? |
|
No worries - I'd leave this open, and focus it on the stdout vs stderr output, as I think that's bound to come up again (as it already has for the gtfs-rt-validator). Both issues are very valid topics for improvements to the validator, IMHO. Could you comment on #256 with your expectations for how it would be implemented, just to document that in context? And 👍 that issue too? |
isabelle-dr
added
help wanted
Is your feature request related to a problem? Please describe.
I'm creating a function on the {gtfstools} R package that wraps the command-line tool and validates a GTFS (
validate_gtfs()). The function also saves the command output (stderr and stdout as separate files) together with the usual validation output.I haven't yet seen case where something was outputted to stdout, but stderr is always full of log messages. These log messages, however, are usually not so relevant to an user that doesn't know the internals of the validator. For example, this is what the stderr of the validation mentioned in #1193 looks like:
Click to see stderr
The SEVERE message aside, none of the other log messages are relevant to an user that doesn't know the tool internals (except the last one, maybe, that summarizes the feed - but even the number of rows in each file is not that relevant of an information). The INFO messages log stuff like the internal validators used, cache hits on each table, the number of threads used, etc.
Thus, important error messages are hidden (or at least harder to see) because they are mixed with informative and not as important to end user messages.
Proposed solution
I suggest adding a command-line parameter (e.g.
--quietor-q) that suppress INFO messages when used. Error messages (such as SEVERE) would always be outputted to stderr, even if this parameter was used.Describe alternatives you've considered
I'm not sure if the suggested behaviour can be accomplished in any other way. I could redirect stderr to /dev/null, for example, but then I'd lose the error messages as well. I could potentially create a "log cleaner" as well, that manually removes the INFO messages and keeps only the error messages, but I'd be much more comfortable doing that from R, thus not benefiting the wider audience that uses this tool from the command-line or from other programming languages.
The text was updated successfully, but these errors were encountered: