Re: [PATCH] progress: use \r as EOL only if isatty(stderr) is true

On Tue, Jun 28, 2011 at 11:33:48AM -0700, Junio C Hamano wrote:

quoted

So far progress always uses \r to produce one-line output on stderr.
This only produces useful and easy parsable output if stderr is opened
on a file which does interpret CR as a real carriage return operation.
This patch changes EOL to the plain newline \n control if isatty() is
false instead.

Signed-off-by: Steffen Daode Nurpmeso <redacted>

I kind of like this patch, in the sense that if there is a sane scenario
to emit progress to non-tty, we should do just LF not CRLF, but I would
like to know the real motivation behind this proposal.

I thought that we try to disable the progress pretty much everywhere when
we are not talking to a tty, so ugliness coming from many CRLF appearing
in the cron e-mail shouldn't be the issue.

We certainly do try to turn off progress reporting when stderr isn't a
tty. So unless "--progress" is being given explicitly, seeing it is a
bug that should be fixed.

I'm not sure dropping the CR is a good thing, though. One of the uses
for forcing output to a non-terminal via "--progress", is that something
_else_ is going to parse the output. And that other thing gets useful
information from the carriage returns.

For example, you may be piping into a file or a fifo and running 'tail'
to a terminal on the other end. You want the CR because we are
ultimately going to a terminal.

Another example: you write a GUI wrapper around git that captures and
parses stderr. You show progress and informative messages in a running
dialog. The difference between CR and LF is important. The former means
"clear the progress line and show this new one instead"; the latter
means "keep this on the screen and show more lines".

I'm willing to accept that there are use cases where you don't want the
CRs, but just want a list of lines[1]. But it seems like this change
hurts some existing use cases.

-Peff

[1] Actually, I would be curious to see such a use case. If you are
planning on saving the output, is it really useful to have a hundred
lines saying:

  Compressing objects 1% (100/10000)
  Compressing objects 2% (200/10000)

and so forth?