Handle stderr vs stdout #75
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
When attempting to handle stdout vs stderr for formatting directives it turns out that it's none-trivial and we should be really consistent with where our stdout and stderr messages go. With that in mind, the changes here ensure that when we encounter an error for a machine format, the EMPTY value for each format is correctly rendered to the STDOUT and not STDERR. stderr is useful for error messages and until we have an appropriate way of putting logs for CLI commands, we should use stderr for constructive information that the consumer can use. For scripting, stderr can always be redirected 2>/dev/null or to any file so they can view what went wrong at a later date.
|
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When attempting to handle stdout vs stderr for formatting directives it
turns out that it's none-trivial and we should be really consistent with
where our stdout and stderr messages go.
With that in mind, the changes here ensure that when we encounter an
error for a machine format, the EMPTY value for each format is correctly
rendered to the STDOUT and not STDERR.
stderr is useful for error messages and until we have an appropriate way
of putting logs for CLI commands, we should use stderr for constructive
information that the consumer can use.
For scripting, stderr can always be redirected 2>/dev/null or to any
file so they can view what went wrong at a later date.