progressbar label should not be shown when the output is not a tty#401
progressbar label should not be shown when the output is not a tty#401pombredanne wants to merge 1 commit intopallets:masterfrom pombredanne:progressbar_redirect
Conversation
|
Sorry for responding so late.
The bar is not displayed, the label is. This is intended behavior I think. |
|
@untitaker I kindly disagree. The label is displayed as part of the bar and is as much part of the bar as the pos, the item show function or anything else. This does pollute a non-tty redirection for no good reason I can fathom. Furthermore, it prints it to a non-tty more than one time. |
|
and @untitaker it would be nice not to close the PR abruptly without a discussion first |
|
@pombredanne You make this seem like a bug when it's not. This is intended behavior -- the label contains information about the work that is currently done by the launched program. Since you can't output anything else while the progressbar is running (without creating glitches), this is the only option to show any information at all, besides the progressbar itself. Your fix would make any well-behaved Click app effectively silent in non-TTY mode. |
|
If you want to discuss the current behavior, please do open an issue for it. |
|
@untitaker fair enough I created #406 as an issue. |
If you pass a label to a progressbar, the label is incorrectly included when you redirect the command output to a file.
The docstring states: "By default, this progress bar will not be rendered if the file is not a terminal."
However, the label is always displayed even when the output is not a tty.
The
render_finishfunction does this correctly:https://github.com/mitsuhiko/click/blob/36f83d91e27b5b88ee806cb40f284658e2f9cdb5/click/_termui_impl.py#L106
In contrast
render_progressalways prints a label even ifself.is_hidden, and should just return instead without any echo:https://github.com/mitsuhiko/click/blob/36f83d91e27b5b88ee806cb40f284658e2f9cdb5/click/_termui_impl.py#L183
This simple command shows the issue:
This is correct:
This is not:
I would expect the redirected stdout to be empty in this case.
This commit fixes this.