Re: [PATCH] test-lib.sh: use printf instead of echo

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 19, 2014, 19:24 UTC
Message-ID: <xmqqob122dq0.fsf@gitster.dls.corp.google.com>
In-Reply-To: <871txygl27.fsf@fencepost.gnu.org>

David Kastrup <dak@gnu.org> writes:

Show 26 quoted lines

> Junio C Hamano <gitster@pobox.com> writes:
>
>> Jonathan Nieder <jrnieder@gmail.com> writes:
>>
>>> Junio C Hamano wrote:
>>>>> Uwe Storbeck wrote:
>>>
>>>>>> +	printf '%s\n' "$@" | sed -e 's/^/#	/'
>>>>
>>>> This is wrong, isn't it?  Why do we want one line per item here?
>>>
>>> Yes, Hannes caught the same, too.  Sorry for the sloppiness.
>>>
>>> We currently use "echo" all over the place (e.g., 'echo "$path"' in
>>> git-sh-setup), and every time we fix it there is a chance of making
>>> mistakes.  I wonder if it would make sense to add a helper to make the
>>> echo calls easier to replace:
>>
>> I agree that we would benefit from having a helper to print a single
>> line, which we very often do, without having to worry about the
>> boilerplate '%s\n' of printf or the portability gotcha of echo.
>>
>> I am a bit reluctant to name the helper "sane_echo" to declare "echo
>> that interprets backslashes in the string is insane", though.
>
> raw_echo

Yeah, but the thing is, this is not even "raw" if you view it from the direction of knowing what "echo" does. That is why I repeated "helper to print a single line", which is a viewpoint from the user side. "We do not care how it is implemented, we just want a single line printed" is what we want to express, which "say" is perfectly in line with. "We use a subset semantics of 'echo' to implement it" is of secondary concern.