Cargo doesn't clear line when progress bars force-enabled

[joshtriplett]

When building with CARGO_TERM_PROGRESS_WIDTH=100 CARGO_TERM_PROGRESS_WHEN=always cargo build, with stdout/stderr directed somewhere other than a tty, cargo doesn't seem to clear to the end of the line when overwriting a line containing a progress bar.

Correct behavior, with stdout/stderr going to a terminal:

~/src/cargo$ CARGO_TERM_PROGRESS_WIDTH=100 CARGO_TERM_PROGRESS_WHEN=always cargo build
   Compiling libc v0.2.86
   Compiling pkg-config v0.3.16
   Compiling cfg-if v0.1.10
   Compiling autocfg v0.1.6
   Compiling lazy_static v1.4.0
   Compiling proc-macro2 v1.0.5
    Building [                                                         ] 2/153: libc(build.rs),...

Incorrect behavior, with stdout/stderr going to a pipe:

~/src/cargo$ CARGO_TERM_PROGRESS_WIDTH=100 CARGO_TERM_PROGRESS_WHEN=always cargo build 2>&1 | cat
   Compiling libc v0.2.86
   Compiling pkg-config v0.3.16
   Compiling cfg-if v0.1.10
   Compiling autocfg v0.1.6
   Compiling lazy_static v1.4.0                                        ] 0/153: pkg-config, cfg...
   Compiling proc-macro2 v1.0.5                                        ] 1/153: pkg-config, aut...
   Compiling unicode-xid v0.2.0                                        ] 2/153: proc-macro2(bui...
   Compiling syn v1.0.5                                                ] 3/153: proc-macro2(bui...
   Compiling serde v1.0.101                                            ] 4/153: proc-macro2(bui...
   Compiling memchr v2.2.1                                             ] 5/153: proc-macro2(bui...
    Building [=>                                                       ] 6/153: pkg-config, ser...

(Letting it run longer shows that the ===> part of the progress bar doesn't get cleared either.)

[ehuss]

I think this is expected behavior. When you pipe stderr, it disables ANSI codes, so the progress bar uses a carriage-return to clear the line. cat probably doesn't handle carriage return like you would expect. If you want the progress bar and ANSI codes, you'll need to also pass --colors=always (or the term.color cfg option).

[joshtriplett]

@ehuss I saw this behavior whether I used CARGO_TERM_COLOR=always or not.

[joshtriplett]

The detection of stderr being a tty or not does seem to be the issue, though: if I change err_erase_line to skip checking if stderr is a tty, this issue disappears.

Would it make sense for Cargo to skip checking if stderr is a tty if it's being forced to display a progress bar? Or, alternatively, would it make sense for Cargo to clear the line with spaces rather than the clear-to-EOL escape sequence, if emitting a progress bar but ANSI sequences aren't force-enabled?

[ehuss]

Oh, sorry, I was mistaken. The issue is this line:

cargo/src/cargo/core/shell.rs

Line 189 in ab64d13

stderr_tty: true, ..

Yea, I think instead of checking for tty, it needs to check if color is enabled. If not enabled, it can maybe clear with spaces? If color is enabled, then it can use ANSI to clear. I think Windows can just always use spaces.

[joshtriplett]

#9231 partly fixes this, for the case where progress and color are both force-enabled.