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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Danny Lin <danny0838@xxxxxxxxx> 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?


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]