Repository navigation
Fall back to verbose mode when terminal width can not be safely obtained - #513
Merged
Merged
Conversation
get_console_width() is used to get the console width for calculations related to output, like the progress bar, but get_console_width() currently inquires fd 0 (stdin). If stdin is redirected, the returned width will not be correct. Inquire stdout instead of stdin, to get the correct output width. Signed-off-by: Torleiv Sundre <torleiv@huddly.com>
print_oneline() unconditionally converts the returned int from get_console_width() to a size_t, without verifying that the returned value is non-negative. Store the returned width in an int, which will prevent calculation of nonsensical process bar widths, as was the case before "46d798b Fix garbage value of console width when no pty". Change the type of the min() with the string length to int, which should be safe for any reasonable string size. Signed-off-by: Torleiv Sundre <torleiv@huddly.com>
Fall back to the verbose mode (no progress bar) if stdout is not a TTY, for example when piped to another process. Signed-off-by: Torleiv Sundre <torleiv@huddly.com>
"46d798b Fix garbage value of terminal width when no pty" fixed an issue, where a failure to obtain the terminal width falls back to a fallback width of 300 characters. uuu already has a verbose mode, that is more suitable in situations where the terminal width can not be found. Fall back to this mode, instead of setting a fixed width, in all cases where the terminal width can not be found. Also fall back to verbose mode if the terminal width is very small. For now, set the limit to 3, which matches the cutoff used in print_oneline(). Signed-off-by: Torleiv Sundre <torleiv@huddly.com>
Don't trust the returned buffer info when GetConsoleScreenBufferInfo fails. Return -1 on failure, matching the non-WIN32 implementation of get_console_width(). Signed-off-by: Torleiv Sundre <torleiv@huddly.com>
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
46d798b fixed an issue where an indeterminate terminal width ended up with a very large width being used, causing a lot of extra spaces in the output.
46d798b solves this by falling back to a width of 300. This helps, but using a default width is perhaps not likely to produce the best result.
In this PR, I have added a series of commits that causes
uuuto fall back to verbose mode in several cases where it does not make sense to output the progress bar.Note that the Windows change is not tested, since I don't have access to such antiquated technology.