Re: [PATCH] contrib/subtree: fix linefeeds trimming for cmd_split()

From: Danny Lin <danny0838@gmail.com>
Date: May 6, 2015, 09:57 UTC
Message-ID: <CAMbsUu6=U92TRo-UeOL1qtaTipMQFzD+m+wM7sn1o-AjD6LJBw@mail.gmail.com>
In-Reply-To: <xmqq4mnqet5d.fsf@gitster.dls.corp.google.com>

Thank you for clearifying this. It seems that it's my terminal trimming the <CR> from the source code.

If I run a script file with: echo -n "Hello, world1<CR>" echo -n "Hello, world2<CR>" echo -n "Hello, world3<CR>" echo -n "Hello, world4<CR>"

I get this on the screen: Hello, world1Hello, world2Hello, world3Hello, world4

If I run with: printf "Hello, world1\r" printf "Hello, world2\r" printf "Hello, world3\r" printf "Hello, world4\r"

I get this on the screen: Hello, world4

I don't see a problem in 'git fetch' or 'git checkout'

Maybe using printf is the way to go?

2015-05-06 3:11 GMT+08:00 Junio C Hamano <gitster@pobox.com>:

Show 29 quoted lines

> Danny Lin <danny0838@gmail.com> writes:
>
>>> I think this was written knowing that "say" is merely a thin wrapper
>>> of "echo" (which is a bad manner but happens to be correct) and
>>> assuming that everybody's "echo" understands "-n" (which is not a
>>> good assumption) to implement "progress display" that shows the "N
>>> out of M done" output over and over on the same physical line.
>>>
>>> So,... contrary to your "makes no sense" claim, what it tries to do
>>> makes perfect sense to me, even though its execution seems somewhat
>>> poor.
>>>
>> The original version has a CR (yes, it's CR, not LF) at the end of the
>> "say -n" string, which is weird. If it's meant to print a linefeed, we should
>> remove the CR and use "say". If it's meant not to print a linefeed, we still
>> should remove the CR.
>
> Neither.  It is meant to print a carriage-return, i.e. "go back to
> the left-most column on the same line, without feeding a new line to
> the terminal (causing the output to scroll-up by one line)".
>
> It sounds to me that your terminal is not supporting carriage-return
> in a way everybody else expects it to?  It is not just this script,
> but all the progress output we generate use CR for that purpose.
>
> Do you see a similar "garbled" output from say "git fetch" or "git
> checkout" that takes more than a few hundred milliseconds?
>
>