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

From: Jeff King <peff@peff.net>
Date: Jun 28, 2011, 22:45 UTC
Message-ID: <20110628224516.GB4192@sigill.intra.peff.net>
In-Reply-To: <7vwrg5u7oz.fsf@alter.siamese.dyndns.org>

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

Show 15 quoted lines

> > 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 <sdaoden@gmail.com>
> 
> 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?